CN12S1561A Waveform and frame structure for fixed wireless loop synchronous CDMA 
communications system 

Bibliography 
DWPI Title 

Waveform and frame structure for fixed wireless loop synchronous CDMA communications system 
English Title 

Waveform and frame structure for fixed wireless loop synchronous CDMA communications system 

Assignee/Applicant 

Standardized : L 3 COMM CORP 

Inventor 

STEPHENSON P L; GIALLORENZI T R ; HARRIS J M 

Publication Date (Kind Code) 

2001-01-24 (A) 

Application Number / Date 

CN1998812005A/ 1998-11-16 

Priority Number / Date / Country 

US1997988026A/ 1997-12-10 / US 
CN1998812005A/ 1998-11-16 / CN 

Abstract 



imWkmmummiM [51]Int - C1? 

G06F 11/10 

.r. M „ ... ^ , _ „ rt H04J 3/24 H04L 1/02 

[12] tit fWMJfWtS H04B 15/00 H04K 1/00 

[21] fpff^- 98812005.4 



[43]*3f H 2001 ^ 1 J 24 H CN 1281561A 



[221**0 1398.11.16 [21]$^ 98812005.4 


[74]*ipifta«iw 










[32] 1997. 12. 10 [33] US [31]08/988,026 






[86] mmm PGT/US9S/24472 1998.11.16 






[87]BR*&* WO99/30234 H 1999.6.17 






[85]5§AB»&8ta)» 2000.6.9 






[71]#i»A L-3aMSI 






suit £Bffi&#! 












j • m • «mj9t l • a . %$m&m 












R • 










f$2K»f$ 10E»B3I»5H 



[57] «* 

«l£;(b)X!fja:-3RlUlE*» ( 54) I/Q»5cJtf 
^fiftW-4-J!t(62A.62B)i(c)# R^A»A&-«B 

& i/Q »7e6^»itt;»<d)^-iir«*r^: tfr.M^l 
wmfkmpi pn> r«w( we) #&-i8s% i/q sstwsi 




*L A * * 4$ 



jb (pn) i/q *i 

#->NMi ******* 

J* I Q 4/5 ifc**ttf 



8.*uH*# 7 4* X * * ^##J >H 4$ fete- #) * 4*.** 

*t&#lt#$3&# 1/2 ii+4MM**&, H*H*»-* Q 

«; *» 

*fr I Q 4/5 &*j|fciS*MM6^. 

10.- CDMA B ^fe-^^^^L^^-it 
(RBU), ^%#N^^^J^r#X> (SU) fflCDMA^^tf 
iiil/ft, it RBU 

4** SUtt*#jNMi#4JL* * 
#«^ft#«fc*#«*4«»^«^^***1f. 
5ff4«b*fefc**? **JiK4tf«->Hr?; 

~-^j1#&> ®±&FMXM i/q ^ic^^#^"-^^#^i# 

SU. 

-*l/2 ^ 

4/5 3±+#.mm*-m*k*. 
^*tt^*-^****J*4^«i»^-, *-^«t#jjir4^ft*fc* 

-*£*1Mfc*li*4**&->MF-*. 



$jt&0,X*fi$ CDMA 

iX^r*.*!****. 

r a| W A * * f # a # *. * 

**I$t H) * 7. sonet 

xHte&£f£tf'J7^&. 

20 

jM.&JI!|&-*. #*f\ Jfr$#AttA**.lfcft4Mr£*. B*. *. 



*# "W^JUM**", FWL, ##jUfc-f j£JMr*#* 

« amps( £ 

$ &£&&M.#it*&^;g:iMlt ! f 1 TDMA 
DECT # . 

£tf (bespoke systems) & 
B#«#ft*jM^J*fcte. J*-FAn*****B, ^rm« DECT 

(pn) r****. £-*#itiiM8i**pii*tffl*l (I) 
(Q) zk/txfirM (**#HT) H, 

£ ft & . ****** ft 

**«ji*.**-*t«-^«.««^*"**ftA. 



****** 9 **jMt£*IHt--#iAUfc7 $ n 1L&%*^% 

i£Jt^^-#;t>£, CDMA it# tt 

( a) 4MU*iHHJ#AJLJ« ( b) 

^, I/Q^fc*^£#at; (c) I/Q ^ic*h&& 

( P n) ^m^^itQ^^^^^nf^^m. 

JJ£«i*A**fr*f-, #-***:*fc4**t« 

>MMH#l&^&5M'Hfcll£#'& J ?£. ( data integrity fields). 

4*J|?*&&( a) tfftHSfcifclf 1/2 
ii*4M***l, ^^-^I^it^-^Q^ii; (b) *tI*»Qft 
ifi£# 4/5 (pjinctured) *MM**I. 

q i A**.* bs-cdma n^^M^M-^mtm. 

8, *iHt3|r-^iLAtJtJft+it (RBU) ^ 



#-tg ( SU). RBU & SU Jl SUMfil ( side channel) <ff-§-, #>tfd&# 

SU #*t^JiA^#^#^^«#^. 

® 3 &jUf ® 1 ^r^ RBU^SU##®. 

g 5A 5B jtiffc Jfe^jfliflSB RBU JL#;fc##t&^. 
Bfcjtifcfcfc (FWS) 10jt-^J.-fit*ie.l|**L*^3t#J*li. * 

FWS 10 *it$t^*rt&'f c» MA & 

fcjf*4Mfr, i-^lf^f 
A FWS 10 4HI T#**FM*t* 
fcttfcJf**********'. IWS 10 

it**** (mini) IMo^t^^ 

FWS 10 # — &£*!Hfcfefc: « 32 kbps ^IM*^* 

FWS 10 £*&4Nit## CDMA&*$.M| JLte, *t^-f 
^Jbt(TDMA) 

FWS 10^— CDMA ( S-CDMA ) iH£$Sfc, £t^^& 
Ufc^X, (RBU) 12 3 &JL (SU) 

14, 6§jE.&#J& (FL) Jl&#^«I*TJi^^^^#, *t** 
SU14 J*3-f#>&FL#-f, #£$,iSJ#„ SU 14 

(RL) Ji^^^-f ^ RBU 12, Vlitik'Z%LM& RBI! 12 A*!*-*** 
BtfaJW# s FWS 10 -f £ RBU 12 

SU 14 41 pq &«4f-iM-^/A#:4frtf **t. 

SU i4#A/8>*fc$*:4MCPE) ** CFE&fe#-*H 
(NTU) i(»»-^W*rt* (UPS), B liWib. 

rbu 12 ( mr i~%r n) bii 



j£k&-+&mjiMtiinf&ft3t < SIDE_CHAN) 

12bti&tHft.l2a4UT, fVtttoStftHM. £FLJLfc#Bj\ 
*.jfe#iE*.i«*J, BtSU 14#&&^i£^*i42-#«lf, iKft^t 
&#J*!*I (I) ^Jt^t (Q) RBU 12 ft#££**&i&4H£ 

4-^ 128 >MI#if ( code channel), & 
t^#-t#&!SA 2-3 GHz. 

RBU 12 12c, 12c ft* ife JMMTil*#t 

#.l2d&«. it-ii^it#*ii^L I2d 4k&4k&fa 12c #j -|r M 4f f . tfs 

12c. rtiaiH^HrtTsU.Bfctf, 
fc4£i£jtjMHf-f-« SU 14 A*. 54.#at**t*.12d*A- 

^MM^/iMfr*!^^* RBU £#)3ll2e, JB dMMB 

*su i4 j£|Ljt##-f , %-mk-^$%-m\tiL%, *»T*#*. */ 

^##iMMEM) 12fJ|LRBU*MW£ 12e M -f #4 

«*Mfc*-*jt (NIU) 13 *ii^-f*Jfc^fl«*l**l**it* 
-fft, 4f RBU 12 (PSTN) 
13a. RBU 12 $ El -f HflL NIU 13 J8 R 12b 
SU14ifiiJi&;£^ 1 fe#tt^RBU12 3t#. 

FWS 10 «&tfc, ^ife^EMSC St^S* ), 
NIU 13 ^ RBU 12 (OAM&P) # 

ft. EMS^^ft^-faHf^HI^^AJ.^*-*-*, HA^fW 
18. 

NIU 13 A $ ft, 10 n #1%: & . £ ** ****** « #T 

*j.*Tft*#«iM£#,fc*&*H** 

— NIU 13 15 4 RBU 

12 RBU 12 M 1 £!| 4 ^ El AultW^ RBU 12 

$4^Eli£#„ J5*K NIU 13 *PT#&***J*» 10000 

/5fr# El -f tfl* 16 NIU 13 RBU 12 



5 



#;ML*fl EMS*JM£&. H-miA^T HDLC 

imj 13|£##JMM&&&&: RBU 12 £.#*fc-?"3-*' 

DTMF#-t^SU 14; £ A > *Mf**HHH& 

H ( CDR) HDLC ( $| RBU *t«#*tl§4MS- 
*«.); A -f**^ tt^fl 

(ccs); £niu, rbu^su l^^^fl; •f'H'ffcitfiif «; 

(POTS) ^ig$# POTS *f *»l-#jtk; 32/64 kbps 
& *3.4M9 (12/16 kHz ^m^^&m, £*MU&; 4fcibM> 

t4^«M; jUfrHfct/a^**, ^^E&M. Rl, R2, R2 £ 
*^C7; ttai*4t*ft4b: I* J^|*^JM* 

SU 14 ^£fX#IUW#^ ITU-T G.721#^^ ADPCMJ6 
J^ar^tfAiStg-MU,. -MfrJf* (toll quality) 60 32 kbps 
£RBU12 2fc^7# XJl^ifc#tf&T&#tt*iUt£( * EMS/NIU 
«Mfcf-f££8t X.21 #$j*fcJLA*A*l*t*. it* 32 

kbps # Jfl -f $ & 9600 b/s 6$ * f £ * f 

&m$#£MMtlft&1t*b4tfc£&64 kbps PCM **HS"f7*4*i*. 
^ft^l.^ 33.6 kbps fMM-^MUHUHI***. 

il- SU-RBU £ f **J&# >Mr ft tfj 2.72 
MHz( &&flM^f *#3.5MHzMfii,&iaI$ 91 MHz 119 MHz 
##X#li^ 2.1-2.3 GHz 2.5-2.7 GHz. ftft, X 
*A*^#<fc*f+^«^i|#*t^«*4f^rrU 283.5 ttftft 
tiJMt*MML1.8£A5GHz. *J-f ITU 283.5 A£, &MT 96 4HK 

**®2#r^. RBU12T#£^f 3'i**#-?-, 

3IftW, SU14£^f 3 MM**, **t3'JL**^-?". 

RBU 12 T & # 2.72 MHz # # f ^ Bfr 128 ^ 34 kbps $ 4t it, 
ltftttf]i£&^i£$} 1.6 b/Hz„ £ii-~-&^-ft, FWSlO&ifJT 8^ 
#it, >Hmti£^2id>ps£*ifc*4ft. 4r*tti 
t- iA 120 ^ 32 kpbs t##ii. 

FWS 10 ^if ^4 i x.-f ^ CDMA 3i* jL$r& ® % FWS 

n^mi^nnf CDMA. T&^&^&M,, fe#Sf-IS-95#«» 



>£ & , RBU 12 SU 14 
^^^Hi, RBU 12 *4M* J SLft4t:it (^SU 14 fj 
RBU12>###. iL*j£& SU14 #*r*4fcii^t 

il-WJF^^^^ilitJlL^^^^t-f Alt, # + 

RBU 12 >l***^|t*ft SU 14 #t$!| 

^/fl****.***!*, *»T£tf*. £&#4t&T, #T**4& 
fr'hB^flOtt'F*., *fc#iRBU**&H*»;arfc. T#£RBU12 J£& 

^^.t^J-^^Ob, #2U£#]&# RBU##s B. 

£-*su i4#*i*j*MMM- ( /8^4f*t#) stta*^ 

T ttf* * ALOHA 6 ^^^^l t^#-iif ^-^ Ji^-^'f 

RBU 12 ftf&-: «:# 

1%^) *^^^SU14„ J?&)*)iH\ RBU 12 *f-&£3t-*r*:i£tt 
^£i3L#j£fc 

jE£M*&&#ii$ SU 14*$$>-&3&4m4»fe&4s 
iUM******. SU 14 ^^Mfc***^******** H 

§ NIU13 JMfliM^frt SU14^>fX8t, RBU 14 it it El 
glfa*. RBU 12 SUM ft. RBU 14 

$fc^j£.i%iifl:iiJi^i^-^^4^ SU 14, it-?#&&4t^#ii^. 

^#f^iMs£^> t?5JL NFU 13 JM»J^&#£ft# SU14^- 



**sui4**ii-+*^#.©Mr£« j »at. #&rbui2 

5 * SU 14 *»**t#***4.**-**i. SU14«fc^ 

3&£#:f ffl 3 *Mh^ RBU 12 SU 14. 

PSTN 13a 6§<fAMit NIU 13-64 kbps ^ El 

13b, rttt El&f 20. El # o 20 :fi&#&&J& 

10 A#ADPCM#&, #64 kbps ^Til^^^ 32 kbps 4£i£4f -f, it A 
PPCM-f^21 fi^Btl*. >^Mfcit7 A# ADPCMil^, it— 64 kbps 
#iUm^J&ft^32kbps#ii, #itA.PPCM^21. 
^ifc^lfc^, RBU12T^i#^iil28^32kbps^#3l, #— >h SU 
14 £#£&4 >h32 kbps##if. it-PPCM^^-21^^^ 

15 P]f ( FrameSync ) Itf 20a i£#X#, 16 msf i-i 

iM**#RBU 12 ^^r^ff ^#Mit PPCM -t^ 21 
^ El 41- a 20. *r*A*A, (BBC) 
22, ^ii-^ D/A 24 fc-^MfiH^ ( RFFE) 26, 

Jt#U2b, Jl#^SU14. £SU14 Jt, i^^ 14a*t^'J'fX#-f , #it 
20 *MMfcRFFE34, A/D 36, J&ffl % 38 **&#t*L 40. SU14&&->M 
r^v^fy (SLIC) 42, fc^-'NMHlHH (PCM) ^*M3#« 
J*.*f*+it (NTU) 52*#**. £*UL#ftJfc., NTU52*.lIt"M, 
Mit SLIC 42 PCM -f 43 $&JUt*L 44, MA H 46, D/A 
48 *» RFFE 50. SU 14», RBU ^ 12b 

25 RFFE 28. A/D 30. fciflS^S 

##-iL 32, &J&&StPPCM- : M&-21**El&i* 20, ifcit El -f- * 13b 
PSTN 13a NIU 13 
RBU 12 FWS 10 **| FWS 10 

PPCM -f * 21 >*£###4££.llt#?t#&fc» FrameSync 

30 20a fe. FWS 10 JL, #;frit*:*fr*i.#A*X/*^*l* 

TtfjM"ffl SA^SB-Bf.qSSI^jtJf-W S-CDMA £ 



RBU 12 JL, (32 kbps) (1.5 kbps) H 

( MUX) 53 ( 34 kbps). £^41 54 A, 

1/2 it*****!. mfe&Tffc 56 «^J& 4/5 ( 4/5 
&**t**MM), Ifr Q^iG*t. &J& SYNC # A MUX 58 # 
5 &m$b SYNC ^ ( 312.5 ^it/#, I SYNC ^ Q SYNC) 

#fJW I/QJ^i&aH 21.25 ^X2j7Lf$r)frM&&M& 60A 60B 

afc^ (2.72 5t^ D/A 24 fr&M RFFE 26, 

io it* ( r-ff) (i#) #at«*^**«. 

**.2L*H#*i!#-*. *#*t**R#*4Mf SU 14fM$&4&£ 
«J4Jf. £iLfc4M&-t«*8#**#M*. ®# RBU 12 &ft*tit&1ft 

Wit*. 4s*. iit^*itJMi*ttfl***, i^t^^/w 

^TtflStf ALOHA ^AL#t1X#T. &ftfaiiit&^i£#*M r $& 

g 5B «* RF&&JMfft3tift*T£#$&? . **HT* 62A^ 
62B X3L-*.Xfi#i6 pH *MHt*#**Hr, 64A*»64B 

3L%fa-^$k7lMM, T^Q^^7t#-J*. #I/Q*fcj!|*tf**: 

SYNC 66. * 66 H JM**, 

20 ***t^ Uepuncture) ft 68 70 # -ftt 8 # I/Q 

4k£*JU**£)|t*ft68, *Jft4UMfc**HtA. **t*ft 

68 70 4&*A, 70 I/Q 

*lx.#tft ifc «>J -ft-y . ft 72 $ M j^-f-;* £->N* 

. i&izf (DEMUX) 74 * -f 

25 «$4. 

itit|Ll^Q#3tJ:^^^#Wpii^, ^ffl^^l^I^Qpn 
%ktfi&$Lfalt, FWS 10 7 -te. 

♦#H4, *&M*tift4&.*£l6mstt4A80 X. f 16 ms^ 
80 4 >M6 ^?*frft*;Mt#**. 80A 3 *1 *^**fc*J 

30 (CTRL) ftit^^msOB. ->N£^&$ 82#£>M Ml, 

*fr * -r tt T Ji -f * A M « - * 

*>NHJ**«M*«* CRC (XOR *»#) *flt 



9 



Ifc^SO^^l^l^PW SYNC ) ^ SOB. it- SYNC ^ 80C 
^iL, «A£&#«J&ia^Lii.*#^ SYNC #A 
MUX 58^, ^^Jlfcj*^^^^ SYNC ^3^*1^* 66 
SYNC ^ 80C * RBU SYNC ^ 80C 

£3*1 ^?^#J&^ 9 -* ftfJ-lt^^ftftll^A 80A Jt, 
80 M.M -*t#fc" A.«i*t«i«4, *iS.jt*t. 

st-^ft4t^ fws io ft#*ai*«**iff^*^*^*f^il: 



10 



* « * B 





2 




3 




4 




5 



(19) 



J 



(12) 



(43) Date of publication: 

02.08.2000 Bulletin 2000/31 

(21) Application number: 00101533.8 

(22) Date of filing: 26.01 .2000 



Europaisches Patentamt 
European Patent Office 
Office europeen des brevets (11) EP 1 024 661 A2 

EUROPEAN PATENT APPLICATION 

(51) Int. CI. 7 : H04N 5/445 



(84) 


Designated Contracting States: 


(72) Inventors: 




AT BE CH CY DE DK ES Fl FR GB GR IE IT LI LU 


■ Gagnon, Gregory J. 




MCNLPTSE 


Torrance, California 90277 (US) 




Designated Extension States: 


• Toellner, Jon D. 




AL LTLVMKROSI 


El Segundo, California 90245 (US) 


(30) 


Priority: 27.01 .1 999 US 2381 27 


(74) Representative: 






Grunecker, Kinkeldey, 


(71) 


Applicant: 


Stockmair & Schwanhausser 




Hughes Electronics Corporation 


Anwaltssozietat 




El Segundo, California 90245-0956 (US) 


Maximilianstrasse 58 






80538 Miinchen (DE) 



(54) Pictographic electronic program guide 

(57) A system and method for displaying a picto- 
graphic program guide (PPG) to assist users in deter- 
mining and selecting television viewing options and 
related services is described. The PPG is constructed 
at receiver stations based on data periodically received 
via a Direct-to-Home (DTH) satellite communication 
system. Preferably, the data decoder of the receiver sta- 
tion is a personal computer or a device having similar 
processing power. The PPG includes still pictures, live 
video broadcasts, still graphics, moving graphics, web 
pages, links and "buttons" that are utilized by the viewer 
to perform a variety of operations, including determining 
program availability, selecting programming or services, 
and launching to related information, programming or 



services. The PPG layout and organization is defined by 
one or more templates, and the basic instructions lor 
building the templates are broadcast to the receiver sta- 
tions. The PPG, according to the present invention, is 
constructed from both real time broadcast data 
("streaming" data) and periodically downloaded and 
stored data ("file" data). By broadcasting the template 
information, along with instructions or I inking -data on 
how to fill in the template using the streaming and file 
data, the broadcaster can easily change the PPG pres- 
entation format by changing the broadcast template 
information. 
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Description 

BACKGROUND OF THE INVENTION 

fa) Field ol the Invention 

[0001] The present invention relates in general 1o 
enterlainment broadcast systems that transmit and 
receive a wide variety of video, audio, software and 
other types of data. More particularly, it relates to a 
multi-channel broadcast system that transmits a 
video/text/graphic-based program guide data stream 
that is used at viewer stations to generate a user inter- 
face that facilitates a user's selection of various pro- 
grams and services. 

fb) Description of Related Art 

[0002] The use ol electronic communications media 
to provide access to large amounts of video, audio, tex- 
tual and data information is becoming more frequent. 
For example, the public switched telephone network 
(PSTN) is routinely used to transmit low speed digital 
data to and from personal computers. Cable television 
infrastructure is used to carry, via coaxial cable, analog 
or digital cable television signals, and may also be used 
to provide high speed Internet connections. In general, 
cable television infrastructures include many head end 
or transmission stations that receive programming from 
a variety of sources, then distribute the programming to 
local subscribers via a coaxial cable network. Large 
Direct-to-Home (DTH) satellite communications sys- 
tems transmit directly to viewers over one hundred fifty 
audio and video channels, along with very high speed 
data. DTH systems typically include a transmission sta- 
tion that transmits audio, video and data to subscriber 
stations, via satellite. 

[0003] One particularly advantageous DTH satellite 
system is the digital satellite television distribution sys- 
tem utilized by the DIRECTV® broadcast service. This 
system transports digital data, digital video and digital 
audio to a viewer's home via high-powered Ku-band sat- 
ellites. The various program providers send program- 
ming material to transmission stations. If the 
programming is received in analog form, it is converted 
to digital. The transmission stations compress the digital 
video/audio programming (if needed), encrypt the video 
and/or audio, and format the information into data 
"packets" that are multiplexed with other data (e.g., 
electronic program guide data) into a plurality of bit- 
streams, which include identifying headers. Each pack- 
etized bitstream is modulated on a carrier and 
transmitted to a satellite, where it is relayed back to 
earth and received and decoded by the viewer's 
receiver station. The receiver station includes a satellite 
antenna and an integrated receiver/decoder (IRD). The 
IRD may be connected to appropriate output devices, 
typically including a video display. 



[0004] In general, DTH satellite(s) broadcast on 
several frequencies from multiple transponders at differ- 
ing polarizalions (e.g., left and right hand circular polar- 
ization), and each transponder bitstream includes the 

5 video and audio data packets (in a compressed format) 
for several different programs (or "viewer channels"). 
For example, transponder one may broadcast the digital 
video and audio data packets for ESPN, TNT, AMC, 
A&E, El, STARZ and USA, in a statistically multiplexed 

w fashion. Satellites or other distribution systems which 
require separate input processing (e.g., satellites at two 
separated locations requiring different antennas) may 
also be used. Accordingly, in order to receive a desired 
viewer channel, the receiver station must know the 

is transponder frequency and the polarization at which the 
desired signal information is being broadcast by the sat- 
ellite, along with the identifying header information for 
those data packets on that transponder that relate to the 
desired program to permit its isolation from the multi- 

20 plexed bitstream. 

[0005] Each satellite transponder broadcasts a pro- 
gram guide data stream, which typically includes not 
only broadcast schedule data, but also the aforemen- 
tioned information that the receiver station needs in 

25 order to tune to a particular channel. The program guide 
data stream is broadcast on all satellite transponders so 
that channel selection information is always available to 
the IRD regardless of the channel to which the IRD is 
tuned. 

30 [0006] The data packets are distinguished from one 
another by their header information, which is referred to 
as the packet's "service channel ID" (SCID). For exam- 
ple, if a viewer instructs the IRD to display ESPN, the 
IRD, via the tuning information in the program guide 

35 data stream, determines the transponder frequency and 
polarization at which the ESPN programming is broad- 
cast, along with the SCIDs of the data packets that are 
needed to generate and display the video, audio, and 
data content of the ESPN program. 

40 [0007] The scheduling data in the program guide 
data packets also provide channel and program- 
attribute information that is used by the IRD to construct 
and oulput as a viewable display (which may be a full or 
a partial screen) a text-based listing of programming 

45 channels, times, titles, descriptions, ratings, etc. In 
operation, a program guide display is typically pre- 
sented as a grid having channels listed along the left, 
times across the top, and program titles shown within 
the grid squares. Users can scroll through the grid, 

so either up and down (by channel) or to the left and right 
(by time). Channels can be selected by inputting the 
channel number directly using the number keys on a 
user's remote control , or channel s may be selected from 
the program guide display by highlighting and selecting 

55 a currently broadcast program that is listed in the grid. In 
either case, the IRD tunes to the chosen channel by 
accessing the channel's transponder (frequency), polar- 
ization, and SCID information denoted by the program 
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guide data stream. 

[0008] An extension of known IRD equipment is a 
PC-based system that allows users to receive, directly 
irrtolheir PC's, the same digital video, audio, and related 
information signals received in conventional DTH sys- 
tems. The receiver station in this PC-based system 
includes a local satellite receiver dish similar to that of a 
conventional IRD syslem, but the IRD functions are 
implemented within Ihe PC architecture through the use 
of one or more circuit boards that are inserted into the 
PC. The decoded outputs from these boards are dis- 
played on the PC's monitor, or may be output to a con- 
ventional video display (e.g., a television set) and/or 
other mass storage medium such as magnetic tape, 
digital video disk (DVD), optical or magnetic disk, video 
recorder (VCR), etc. Because the receiver station 
includes a personal computer, a large number of addi- 
tional data and software-related services can also be 
downloaded directly to the PC, thereby offering a variety 
ol services, including broadcast programming, pay-per- 
view events, audio programming, data services, web- 
casting, software downloads and other data or soft- 
ware-related services. 

[0009] One example of a known electronic program 
guide is described in U.S. Patent No. 5,633,683, entitled 
"Arrangement And Method For Transmitting And 
Receiving Mosaic Video Signals Including Sub-Pictures 
For Easy Selection Of A Program To Be Viewed", issued 
May 27, 1997 to Rosengren et al. The Rosengren et al. 
patent discloses a video-based electronic program 
guide, wherein the available programs are conveyed to 
the viewer by displaying a so-called "mosaic" made up 
at the broadcast site of the live video from each of the 
transmitted channels. The mosaic is essentially a single 
image divided into a plurality of areas, wherein each 
area displays the live video of one of the available pro- 
grams. A user selects a channel by moving a cursor 
over the video area displaying the desired program- 
ming, then pressing a select button on either the televi- 
sion or the user's remote control. The selected live 
video image is then tuned and displayed. In an alterna- 
tive embodiment, the live video in any area of the 
mosaic is automatically replaced with a still picture of 
the program if it is determined that the live broadcast is 
currently a commercial instead of the actual program. 
[0010] Another video-based electronic program 
guide is disclosed in a European patent application enti- 
tled "Television Signal Transmission And Reception 
System With Multi-Screen Display For Tuning Opera- 
tion," published May 25, 1994 and bearing publication 
no. 0 598 576 A2 (filed by Toshiba). The Toshiba EPO 
application, like Rosengren et al., discloses a video- 
based electronic program guide wherein the available 
programs are conveyed to the viewer by displaying a so- 
called "multi-screen" display made up at the broadcast 
site of live video from each ol the transmitted channels. 
The multi-screen is essentially a single screen divided 
into a plurality of areas, wherein each area displays the 



live video of one of the available programs. A user 
selects a channel by moving a cursor over the video 
area corresponding to the desired programming, then 
pressing a select button on either the television or the 

s user's remote control. The selected live video image is 
then tuned and displayed in the full screen. In an alter- 
native embodiment, the video-based program guide is 
applied to a two-way CATV system, and the viewer's ini- 
tial request for program guide information is sent back to 

io the broadcast center which transmits to the viewer a text 
listing of categories into which the available programs 
and channels have been divided. The viewer selects a 
category, and this category selection is transmitted back 
to the broadcast center which may then transmit 

, 5 another listing of subcategories related to the chosen 
category. The viewer continues to select subcategories 
until no further subcategories are available, at which 
time the broadcast center transmits a multi-image 
screen containing only the video images from those pro- 

20 grams that fall in the selected category and subcatego- 
ries. 

[0011] U.S. Patent No. 5,523,796, entitled "Video 
Clip Program Guide" and issued to Marshall et al. on 
June 4, 1996, discloses a text-based program guide laid 

25 out in a grid. Video clips from certain programs are 
stored at the viewer's station, and the programs that 
have video clips available are shown in the grid program 
guide with an icon next to the program's title. A viewer 
who desires to see a video clip selects the icon associ- 

30 ated with the program, and the viewer station runs the 
video clip in a portion of the screen. The rest of the 
screen displays text information such as the program's 
title, channel, start and end times, content description, 
etc. Other program guide and/or mulli-image systems 

35 are disclosed in U.S. Patent Nos. 5,231 ,493; 5,422,674; 
5,398,074; 5,430,486; 5,434,624; 5,442,398; 
5,452,012; and 5,047,867. 

[0012] While known program guides have advan- 
tages, there is still room for improvement, particularly 

40 when considering the large number of data, software, 
video, audio, pay-per-view and other programming serv- 
ices available through present and future DTH satellite 
broadcast services. For example, the viewable display 
generated from electronic program guide data tends to 

45 be presented primarily as text laid out in a grid. The 
processing power of currently available IRD's, while 
appropriate for current DTH programming services, 
inherently limits how the program guide can be dis- 
played, how much information can be incorporated into 

so the guide, and how quickly and efficiently a user can 
move through the guide. These program guides are 
therefore essentially limited to conveying program avail- 
ability and tuning information, and do not have the 
organization and flexibility to effectively support other 

55 services such as software downloads, webpage links 
and downloads, data services, and other functions. 
[001 3] Accordingly, for broadcast systems having a 
large number of services that deliver a large amount of 
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data to relatively sophisticated receiver stations (e.g., a 
PC), there is a need for a broadcast electronic program 
guide and an associated viewable display format and 
content that significantly enhances how the program 
guide can be displayed, how much information can be 
incorporated into the guide, and how quickly and effi- 
ciently the user can move through the guide. 

SUMMARY OF THE INVENTION 

[0014] The present invention provides a method 
and apparatus for efficiently and effectively transmitting, 
receiving, organizing and selecting transmitted data. 
The method and apparatus of the present invention is 
preferably embodied in a user inlerface and related data 
protocols and procedures. The user interface may be 
implemented in the context of a wireless distribution 
system for securely, reliably and inexpensively distribut- 
ing video, audio, data service, software and other serv- 
ices to geographically remote receiver stations. The 
wireless distribution system is preferably a DTH digital 
satellite television distribution system, though other sys- 
tems (e.g., terrestrial wire, cable, or wireless broadcast) 
may also be used in other embodiments. A typical DTH 
digital broadcast system includes a transmission sta- 
tion, a satellite relay, and a receiver station. At the trans- 
mission station, video and audio programming signals 
are digitized in known manners, multiplexed with other 
data signals (such as the data needed to construct a 
program guide display according to the present inven- 
tion), compressed (if required), encoded, mated with 
error correction codes, modulated on carriers, and 
uplinked to a geosynchronous satellite. The satellite 
receives the uplinked signals and rebroadcasls them 
over a footprint that preferably covers a predetermined 
geographical area, for example, the continental United 
States. Receiver stations, which are typically located at 
the user's home or business, receive the satellite sig- 
nals. The receiver stations each include an antenna, 
which preferably is in the form of a satellite dish, along 
with an integrated receiver/decoder (IRD). The antenna 
feeds the received satellite signal to the IRD unit which 
recovers the originally transmitted digital video, audio, 
and data. Other receiver station equipment (e.g., cable 
decoder units) may be used with other distribution sys- 
tems in other embodiments, as is well known in the art. 
[001 5] The present invention is particularly applica- 
ble to a receiver station having sufficient processing 
power to process and generate a program guide display 
and associated features that goes beyond conventional 
video/text/grid program guides. The processing power 
may be incorporated directly into the IRD, for example, 
by adding a more powerful microprocessor, more mem- 
ory, and associated software to the conventional IRD 
circuitry. Alternatively, the receiver station IRD may be 
replaced with a PC having circuit cards that perform the 
IRD functions. A PC-based system significantly 
increases the receiver station's processing power, along 



with the number of services (e.g., dala services and 
software) the receiver station can receive and use. 
Accordingly, the features of the present invention are 
most advantageously utilized by a PC-based (or compa- 

5 rable) receiver station. 

[001 6] A PC-based receiver station suitable for use 
with the present invention includes an antenna, which 
preferably is in the form of a satellite dish, along with a 
PC which, like the above-described IRD, recovers the 

10 originally transmitted digital video, audio, and data. The 
digital broadcast data received from the satellite dish is 
coupled directly into a transport circuit board within the 
PC. The PC's transport circuit board also performs ini- 
tial circuit functions on the signal coupled in from the 

is antenna, including tuning, demodulation, and forward 
error correction (FEC). The transport circuit board 
within the PC also performs similar functions to that of 
the IRD's transport circuit, including channel de-multi- 
plexing, decryption and access determination. The 

20 received digital broadcast data is sent from the trans- 
port circuit to video/audio decoder circuits, which may 
be on the same or separate circuit board. The 
video/audio decoder circuit board decompresses and/or 
decodes the received compressed broadcast signal. 

25 [001 7] In one embodiment of the present invention, 
the transmission station transmits to the receiver sta- 
tions program selection data/information that is used at 
each receiver station to construct an electronic program 
guide and associated display format and content (i.e., a 

30 user interface) that, in contrast to known video-based 
and/or text/video/icon-based electronic program guides, 
significantly enhances how the program guide can be 
displayed, how much information can be incorporated 
into the guide, and how quickly and efficiently a user can 

35 move through the guide. The viewable display format, 
according to the present invention, incorporates moving 
picture video, still pictures, text, links to external data 
sources, graphics and other features that facilitate the 
selection of various programs and services. 

40 [0018] The transmission station (e.g., uplink facility) 
transmits to the receiver stations the pictographic pro- 
gram guide (PPG) data/information needed at each 
receiver station to construct the PPG display. The 
broadcast PPG data can be divided into three catego- 

45 ries. The first is real time conventional text/grid-based 
program guide data. The conventional guide data 
includes schedule and program attribute information, 
along with information that the receiver station needs in 
order to tune to a particular channel. In a typical DTH 

so system, the conventional program guide data stream is 
broadcast on all satellite transponders so that channel 
selection information is always available to the receiver 
station regardless of what channel the receiver station 
is tuned to. In general, tuning the receiver station to a 

55 particular channel requires knowledge of at least the 
satellite transponder on which the channel is broadcast, 
along with polarization information and information 
identifying which data packets on that transponder cor- 
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respond to the channel of interest. 
[001 9] The second category of broadcast PPG data 
may be referred to as "streaming" data, which is real 
time PPG data transmissions other than the conven- 
tional guide data. Streaming data can cover a variety of 
data types including, for example, "ticker" data (stocks, 
sports scores, etc.) and PPG "template" data (i.e., 
instructions to the receiver station on how to construct 
and lay out the display of the PPG). 
[0020] The third category of PPG data may be 
referred to as PPG "file" dala. PPG file data is periodi- 
cally (e.g., once a day at 2:00 a.m.) downloaded to the 
receiver station and stored in memory. File data 
includes various information that is related to the PPG 
but is sufficiently static so that it does not need to be 
sent in real time. For example, the transmitted file data 
may be still pictures related to various channels and/or 
services and used to construct a portion of the PPG dis- 
play, moving video clips related to the various channels 
and/or services and used to construct a portion of the 
PPG display, Web pages related to the various channels 
and/or services, and linking information that identifies 
and provides access to related information. The links 
may connect to either internal resources (e.g., cached 
Web pages) or to external resources (e.g., a URL to an 
external Web site). If the DTH broadcast system 
includes a software feature known as "webcasting," the 
file data may include a data catalog indicating the web- 
casting broadcast schedule. In general, webcasting 
involves accessing at the uplink a variety of web sites 
from the world-wide web, and broadcasting those web 
sites to the subscriber stations at selected times. View- 
ers wishing to receive a particular website would access 
the data catalog to determine the broadcast time and 
channel, and tune their receiver to that channel at the 
designated time. 

[0021] Several examples ot a particular PPG tem- 
plate embodying the present invention are shown in 
FIGS. 2-5. As shown in FIG. 2, for example, the lay- 
out/content of the illustrated PPG screen 220 includes 
five major segments. The first segment is an active 
video segment 222 that displays the video/service 
channel to which the receiver is currently tuned. The 
second segment is a category segment 226. All of the 
available channels are divided into categories such as 
sports, movies, news, data services, etc., and these 
available categories are listed in the category segment 
226. Each category has its own template instructions 
that may be different from or the same as the templates 
in other categories. If the number of programs/services 
in a given category is more than fits on a single tem- 
plate, additional templates in the form of additional tem- 
plate "pages" are created for that category. Selecting a 
particular category selects the template page(s) that 
present the programming/service that fall under that 
category. A third segment, the "page" segment 232, 
allows the user to move around the various pages of a 
template by selecting the page segment 232. 



[0022] The fourth segment is a video/picture seg- 
ment 228 shown as a matrix of six 3:4 aspect ratio areas 
each representing a programming channel or service 
channel that may be accessed by the receiver station. 

s Selecting one of the video/picture areas selects the 
channel associated therewith. The areas are linked to 
the program guide tuning information in the same way 
that the display text-based grids and channel numbers 
are linked to the tuning information. Accordingly, select- 

io ing the video/picture area that represents ESPN, links 
the receiver to the program guide tuning information 
(transponder and SCID) needed to acquire the program 
currently being broadcast on ESPN. An additional fea- 
ture is an information area that can pop up (overlaying a 

?5 portion of the current display) whenever a cursor moves 
over a given video/picture area. The information area 
could provide any desired information about the pro- 
gram, for example, the title, program description, pro- 
gram duration, program rating, etc. 

20 [0023] The fifth segment is the "link" segment, 
which can be found in various areas on a given screen. 
The "links" include graphical interface "buttons" and 
other graphic symbols for selecting certain features 
and/or launching the PPG into various states are pro- 

25 vided for the active video segment 222, the video/pic- 
ture segment 228 and special auxiliary areas 234, 
located at the bottom of a given template page. Each 
link, like the video/picture areas, represents a related 
channel, service or other information that can be 

30 accessed from the PPG. Selecting a link may initiate a 
series of local interactions involving primarily the 
receiver station hardware, or the link may initiate exter- 
nal interactions with other hardware/systems such as 
the Internet. For example, "web" links allow the viewer 

35 to either "pull-up" a related web page stored at the 
receiver station or launch to external equipment/sys- 
tems to access the web-page information, grid-guide 
links allow the viewer to move from the PPG to the grid- 
guide, "preview" links allow the user to select and run 

40 video clips of the program in its video/picture area, "soft- 
ware" links allow users to download related software 
(e.g., computer games, applications software or web 
originated software), "view" links make a given picture 
area active, "full" links put the associated video/picture 

45 area in the full screen, "record" links use the broadcast 
time and channel information associated with a program 
to control a video recorder to record the program at its 
broadcast lime, "buy" links allow users to purchase pay- 
per-view programming or services via conventional 

so i mpulse-pay-per-view purchase screens, and data-cata- 
log links take the user to the webcaster broadcasting 
schedule for the system. 

[0024] The PPG, according to the present inven- 
tion, is constructed from both real time broadcast data 
55 ("stream" data) and periodically down loaded and stored 
data ("file" data). By broadcasting the template informa- 
tion, along with instructions on how to fill in the template 
using the streaming and file data, the broadcaster can 
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easily change the PPG presentation format by changing 
the broadcast template information. In operation, a user 
selects a category, and the channels that fall within the 
selected category are displayed according to a particu- 
lar template format. The templates are a particular lay- 
out and configuration of graphics, still pictures, moving 
pictures and text representing the content of the chan- 
nel and associated information and/or services. Select- 
ing a portion of the PPG display selects the 
programming, channel, service or related data or oper- 
ation represented by that portion of the display. Select- 
ing a portion of the display can involve primarily local 
operations, or can launch to external devices/systems 
such as the Internet. Additionally, by limiting the number 
of video/picture segments thai can be active at any time, 
the present invention avoids the confusion associated 
with known picture-based program guides that have 
from sixteen to twenty-five separate active video areas 
in a given screen of the guide. Thus, the program guide 
of the present invention provides an intuitive system and 
method for browsing and selecting television program- 
ming and a wide variety of broadcast services. 
[0025] The invention itself, together with further 
objects and attendant advantages, will best be under- 
stood by reference to the following detailed description, 
taken in conjunction with the accompanying drawings. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0026] 

FIG. 1 is a diagram of a direct-to-home (DTH) trans- 
mission and reception system capable of broad- 
casting and utilizing dala streams embodying 
aspects of the present invention; 
FIG. 2 illustrates an example of one "page" of a pic- 
tog raphic program guide embodying aspects of the 
present invention; 

FIG. 3 illustrates an example of another "page" of a 
pictographic program guide embodying aspects of 
the present invention; 

FIG. 4 illustrates an example of another "page" of a 
pictographic program guide embodying aspects of 
the present invention; 

FIG. 5 illustrates an example of still another "page" 
of a pictographic program guide embodying 
aspects of the present invention; 
FIG. 6 is a diagram of selected hardware process- 
ing components of the receiver station shown in 
FIG. 1; 

FIG. 7 is a block diagram illustrating one possible 
system architecture within which aspects of the 
present invention may be used; 
FIG. 8 is a diagram illustrating a type of transport 
data packet that may be transmitted via the system 
shown in FIG. 1 ; 

FIG. 9 is a block diagram illustrating a preferred 
data flow through a protocol stack for use with the 



present invention; 

FIG. 10 is a block diagram illustrating a preferred 
method of processing a dala packet for use with the 
above-referenced protocol stack; 
5 FIG. 1 1 is a representation of a BFDP header; 
FIG. 12 is a representation of a UDP header; 
FIG. 13 is a diagram of a version 4 IP packet 
header; 

FIGS. 14A - 14D are block diagrams representing 
10 MPT packets; 

FIGS. 15A and 15B are diagrams representing a 
BARP header and a BARP address record, respec- 
tively; and 

FIGS. 1 6A - 1 6D are sample SDP + records for var- 
15 ious information services that may be used with the 
present invention. 

DESCRIPTION OF THE PREFERRED EMBODI- 
MENTS 

20 

[0027] To facilitate review and understanding of the 
invention and the preferred embodiments, the present 
disclosure has been organized in accordance with the 
headings and sub-headings shown below. 

25 

I. System Overview 

II Pictographic Program Guide (PPG) 

III. Receiver Station Generally 

IV. Receiver Station Architecture 
30 V. Data Packet 

VI. Audio/Video Processing 

VII. Data Processing 

A. Protocol Stack/Broadcast File Download 
as Protocol (BFDP) 

B. Broadcast Address Resolution Protocol 
(BARP) 

C. SDP+ Records 

D. Webcast 

40 

VIII. Conclusion 
I. System Overview 

45 [0028] By the way of example only, the method and 
apparatus of the present invention is disclosed in con- 
nection with a system that broadcasts, via satellite, 
video programming, data services and multimedia data 
(e.g., webpages). It should be understood, however, 

so thai any system requiring intuitive interactive program 
and/or service selection may alternatively employ the 
techniques shown herein. Such systems might include 
other broadcast communications techniques not tradi- 
tionally associated with video programming or the Inter- 

55 net. For example, paging or cellular systems delivering 
news or other information could benefit from certain 
aspects of the method and apparatus of the present 
invention. 



6 



11 



EP 1 024 661 A2 



12 



[0029] Generally, however, the techniques of the 
present invention are best used by broadcast video and 
data systems having a large number of available pro- 
grams, data and services, thereby benefitting from the 
simplification of programming organization and selec- 
tion provided by the present invention. A preferred 
broadcasting system is the satellite-based system uti- 
lized by the DIRECTV® broadcast service. Such 
embodiments of the present invention employ a satellite 
receiving antenna to acquire real-time video broadcasts 
and periodic data broadcasts used to construct a pro- 
gram guide display. It should be understood, however, 
that many other delivery systems are readily applicable 
to alternate embodiments of the present invention. Such 
systems include wired or cable distribution systems, 
UHF/VHF radio frequency systems or other terrestrial 
broadcast systems (e.g., MMDS, LMDS, etc.), and liber 
optic networks. 

[0030] FIG. 1 illustrates a typical Direct-to-Home 
(DTH) PC-based satellite communication system 100 
capable of utilizing the present invention. The system 
1 00 includes a transmission station 1 02, a satellite/relay 
104, and a plurality of receiver stations, one ol which is 
shown at reference numeral 106. Wireless communica- 
tions are provided between the transmission station 
1 02, the satellite/relay 1 04, and the receiver station 1 06. 
The transmission station 102 includes programming 
sources 108, a control data source 110, a data service 
source 112, one or more program guide data sources 
1 14, a video/audio/data encoding system 1 16, an uplink 
frequency converter 118, and an uplink antenna 120. 
The data service source 1 1 2 receives data service infor- 
mation and webpages made up of text files, graphics, 
audio, video, software, etc. from a network 122 (e.g., the 
Internet, a LAN or a WAN). The satellite/relay 104 is 
preferably at least one geosynchronous or geo-station- 
ary satellite. The receiver station 106 shown in FIG. 1 
includes a reception antenna 124 connected to a low- 
noise-block (LNB) 126, and an integrated 
receiver/decoder (IRD) embodied in a personal compu- 
ter (PC) 128 having a monitor 130 and a computing unit 
132. Other devices, such as another video display 
device (e.g., television) 134 and a video recorder 136 
(e.g. VHS, DVHS, DVD, etc.), may also be supported, if 
desired. 

[0031] In operation, the programming sources 108 
receive video and audio programming from a number of 
sources, including satellites, terrestrial fiber optics, 
cable, or tape. The received programming signals, 
along with data signals from the control data source 
110, the data service source 112, and the program 
guide data sources 114, are sent to the 
video/audio/data encoding system 116 where they are 
digitally encoded into information data streams that are 
multiplexed into a packetized data stream or bitstream 
using a number of conventional algorithms. Each data 
packet within the packetized data stream includes a 
header that identifies the contents of the data packet 



and a service channel identifier (SCID) that identifies 
the data packet. In a conventional manner, the encoded 
bitstream is modulated and sent Ihrough the uplink fre- 
quency convener 118, which converts the modulated 

s encoded bitstream to a frequency band suitable lor 
reception by the satellite/relay 104. The modulated, 
encoded bitstream is then routed from the uplink fre- 
quency converter 1 18 to the uplink antenna 120 where 
it is broadcast toward the satellite/relay 1 04. The satel- 

io lite/relay 104 receives the modulated, encoded bit- 
stream and re-broadcasts it downward toward an area 
on earth that includes the receiver station 106. The 
reception antenna 124 ol the receiver station 106 
receives the signal, which is typically shitted from, lor 

, 5 example, the Ku-band signal down to, for example, an L- 
band signal by the LNB 126. The LNB output is then 
provided to the PC 128, the television 134 and/or the 
video recorder 136. As noted above, the PC 128 
includes conventional IRD functions (provided, lor 

20 example, by plug-in circuit cards (boards). Thus, when 
the user commands the PC 128 to tune to a particular 
program, the PC 128 associates the user's program 
selection with a transponder and SCID number and 
tunes the IRD to receive data packets from the appropri- 

25 ate transponder and to select data packets having the 
appropriate SCID number from the multi-program data 
stream. 

[0032] Although not necessary for proper operation 
of the disclosed system, the receiver station 1 06 may 
30 optionally incorporate a connection (e.g., Ethernet cir- 
cuit or modem) to the network 122 for transmitting 
requests and other data back to the transmission station 
102 or other location (or a device managing the trans- 
mission station 1 02 and overall flow of data in the sys- 
35 tern 100) and for communicating with network devices 
138 (e.g., websites) that may be on the network 122. 
[0033] In general, the software executed by the PC 
128 includes many conventional PC operations used to 
generate a pidographic program guide (PPG) having a 
40 mouse-controlled cursor or the like, windows, dialogue 
boxes, buttons, and other such features that facilitate 
user selection of various options. The PPG of the 
present invention is assembled using two basic types of 
external data: (1) real-time broadcast data (e.g. stream- 
's ing data), and (2) file data (i.e., data that is periodically 
downloaded and stored). Real-time data includes con- 
ventional program guide data (e.g., program attribute 
data, tuning data, etc.), ticker data (e.g., stocks, sports 
scores, etc.), some SDP+ records, and announcements 
so (e.g., updates to the webcast data catalog, etc.). File 
data includes information that is updated periodically 
such as still pictures, moving video clips, webpages, 
data catalog (webcast schedule), links to other internal 
or external sources of information, and various discrete 
55 software downloads. The PPG of the present invention 
organizes and simplifies the presentation of real-time 
broadcast data and file data by providing, inter alia, a 
plurality of pages, wherein each page has a display with 
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several distinct segments. For example, a given page 
type may simultaneously provide still pictures, moving 
videos, text, graphics, audio, and data within separale 
segments. 

[0034] The PPG of the present invention requires 
the presence of appropriate data at the receiver station 
106. One method of generating appropriate data and 
reliably transferring it to the receiver station 106 using a 
hardware configuration as shown in FIG. 1, is disclosed 
in detail below in section VII of this disclosure. Gener- 
ally, the method set forth in section VII includes a dala 
transfer technique, referred to herein as broadcast tile 
download protocol (BFDP), that operates in a one-way 
broadcast communication link. BFDP is the subject of a 
co-pending commonly assigned application entitled 
filed on and bear- 
ing serial no. I . BFDP breaks 

large data files for transmission into numerous small 
data packets, which are labeled in a sequential manner 
at the transmission station 1 02 and broadcast to the 
receiver station 106. BFDP facilitates the assembly of 
the labeled data packets back into the large data file and 
enables identification of missing or corrupt data packets 
at the receiver station 106. Any missing or corrupt data 
packets at the receiver station 1 06 can be obtained and 
inserted into their correct locations in the large data file 
during subsequent transmissions of the large data file. 
Thus, if during the transmission of a large data file a 
number of its data packets are missing or corrupt, only 
the missing or corrupt data packets need be reacquired 
during a subsequent re-broadcast of the large data file, 
and not the entire large data file. 
[0035] A method for resolving an Internet protocol 
(IP) address into a physical address is also described in 
section VII of this disclosure. This method is referred to 
herein as a broadcast address resolution protocol 
(BARP). BARP is the subject of a co-pending commonly 

assigned application entitled 

filed on and bearing serial no. 

I . BARP is necessary because 

all file data (for example a large file transferred using 
BFDP, as discussed above) transferred to the receiver 
station 1 06 are identified by IP addresses and, as previ- 
ously noted, the receiver station 106 requires a trans- 
ponder and SCID to tune to receive the broadcast file 
data. Accordingly, BARP allows the receiver station 106 
to rapidly resolve an IP address for a desired program or 
service into a transponder and SCID. 
[0036] To inform the user of when and on what IP 
address the large file mentioned above will be broad- 
cast, session description protocol plus (SDP+) records 
are periodically broadcast by the transmission station 
102. SDP + records are the subject of a co-pending 
commonly assigned application entitled 
filed on and bear- 
ing serial no. __/ . SDP + records 

are processed by the receiver station 106 to produce a 
schedule of all data service information that will be 



broadcast by the transmission station 102. Additionally, 
the SDP + records are used by the PC 1 28 to build PPG 
pages using selected information resident within Ihe PC 
system (e.g., a basic page template) and selected 

5 dynamic data that is received from the satellite or an 
Internet connection. When the user launches the inter- 
face into another slate or page, the PPG builds the des- 
tination page as instructed by the SDP + records and 
displays it on the user's PC system monitor 130. More 

w details about the SDP + records are provided in Section 
I of this disclosure in connection with the descriptions of 
FIGS. 16A-16D. 

II. Pictographic Program Guide (PPG) 

15 

[0037] Several examples of a particular PPG tem- 
plate embodying aspects of the present invention are 
shown in FIGS. 2-5. As shown in FIG. 2, for example, 
the layout/content of the illustrated PPG page 220 

20 includes five major segments. The first segment is an 
active video segment 222 that displays the video/serv- 
ice channel to which the receiver is currently tuned. As 
shown in FIG. 2, a plurality of graphic buttons or links 
224 may be displayed adjacent to the active video 

25 image 222. These graphic buttons or links 224, when 
selected by the user, launch the PPG into one of a plu- 
rality of corresponding states that provide additional 
services or data associated with the active video image 
222. For example, selecting a "Grid" button transitions 

30 the active video/audio area 222 to the program grid- 
guide. Selecting a "Full" button may zoom the active 
video segment 222 to occupy a substantial portion of 
the display. Selecting a "Web" button could replace the 
video/picture segment 222 with a web page related to 

35 the currently tuned channel. For example, the "web" but- 
ton could bring up on an available area of the template 
a list of available web pages. The list of available web 
pages could replace the list of categories in a category 
area 226 that is discussed in more detail below. Also, as 

40 discussed in more detail below, selection of the "Web" 
button could invoke the retrieval of webpage information 
that is locally cached at the PC 128 or may, alternatively, 
invoke the PC 128 to access various websites 138 via 
the Internet connection 122 to download and display 

45 webpage information as needed. 

[0038] The second segment of the template 220 is 
the category segment 226. All available channels are 
classified into topics and displayed in the category seg- 
ment 226 as a list of categories that includes, but is not 

so limited to, sports, movies, family, travel, favorites, news, 
data services, category related web pages, etc. Topic 
classifications could be directed by the broadcaster, by 
the user, or a combination thereof. For example, a user 
may create a 'Favorites' category and fill it by dragging 

55 a video area from a video/picture segment 228 to the 
category list 226. In other embodiments, a favorites cat- 
egory is automatically constructed via software resident 
in the PC 1 28 that observes the user's viewing habits. 
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[0039] The user selects a category by positioning a 
cursor using a selection device such as a mouse, keys, 
or remole control to highlight the desired category lor 
display. The currently selected category is displayed in 
an area 230 of the page 220. Each category has its own 
template instructions that may be different from or the 
same as the templates in other categories. Thus, the 
layout, graphics, and other content of the various tem- 
plates can be optimized for the subject matter of each 
category. For example, the templale for the "News" cat- 
egory could include a late breaking news banner in a 
portion of the display, whereas the template for the 
"Shopping" category could include a promotional ban- 
ner advertising/featuring various products and services. 
[0040] If the number ol programs/services in a 
given category is more than fits on a single page addi- 
tional pages are created for that category. Selecting a 
particular category selects the template page(s) that 
present the programming/service that fall under that 
category. A third segment, the "page" segment 232, 
allows the user to sequence through the various pages 
associated with a selected category template. The user 
may, for example, select a right facing arrow to advance 
through the associated pages and a left facing arrow to 
return to previous pages. A second page associated 
with the page shown in FIG. 1 is illustrated, for example, 
in FIG. 3. 

[0041 ] The fourth segment is the video/picture seg- 
ment 228 that preferably includes a matrix of six 3:4 
aspect ratio areas each representing a programming 
channel or service channel, associated with the cur- 
rently selected category, thai may be accessed by the 
receiver station 106. Each video area could include still 
pictures, still graphics, moving graphics, live broad- 
casts, text, or a combination thereof representing the 
content of the program currently being broadcast on 
that channel, or for some program that will be broadcast 
on that channel in the future. 
[0042] Delivery of the video/picture area may be 
accomplished via the live video broadcast, such as by 
freezing a frame or displaying live action or periodically 
sampled video. However, in preferred embodiments, the 
pictogram representing the program is selected by the 
program provider, broadcaster, or others to be a pre- 
ferred, symbol, graphic, picture or other pictogram illus- 
trative of the program content. In these embodiments, 
the pictogram data may be broadcast independently of 
the program content (e.g., well in advance for guides 
showing upcoming programs) via broadcast data, 
retrieved data, or a combination thereof. One or more of 
the video areas can be made "active" (i.e., the live 
broadcast) according to user's desires and the decod- 
ing capabilities of the user's video/audio decoder hard- 
ware/software. Accordingly, the user can have as many 
active video areas as desired. 
[0043] Selecting one of the video/picture areas 
selects the channel associated therewith and displays it 
in the active video segment 222. The video/picture 



areas are linked to the conventional program guide tun- 
ing information in the same way that known text-based 
program grids and channel numbers are linked to the 
tuning information. Accordingly, selecting the video/pic- 
s ture area that represents ESPN, for example, links the 
receiver 106 to the conventional program guide tuning 
information (channel frequency, polarization, header ID, 
etc.) needed to acquire the program currently being 
broadcast on ESPN. 
io [0044] An additional feature of the video/picture 
segmenl 228 is an information area that can pop up 
(i.e., a child window) whenever a cursor rolls over a 
given portion of a video/picture area. The information 
area may provide any desired information about the pro- 
is gram, for example, the title, program description, pro- 
gram duration, program rating, etc. Such information is 
typically broadcast in conjunction wilh known guide sys- 
tems 1o provide users with information regarding a pro- 
gram. 

20 [0045] The fifth segment is a "link" segment, which 
can be found in various areas on a given screen. Links 
(including graphical interface "buttons" for selecting cer- 
tain features and/or operations) may be provided for the 
active video segment 222 and/or special auxiliary areas 

25 234 located at the bottom of a given template page. In 
one embodiment of the present invention, links may be 
provided in association with (e.g., within or adjacent to) 
one or more of the video/picture segments 228. 
[0046] When the user selects a link an action is 

30 taken. For example, "web" links may be provided that 
allow the viewer to "pull-up" a related webpage previ- 
ously downloaded from the satellite 104 and cached in 
the PC 1 28, or that is retrieved via the network connec- 
tion 122 when requested. Alternatively, selecting the 

35 "web" link could bring up on an available area of the 
template 220 a list of available web pages. When "grid- 
guide" links are selected, a conventional grid-based 
program guide is displayed to the user. When "preview" 
links are selected, the user may select and run previ- 

40 ously stored or retrieved video clips of the program in its 
video/picture area. When "software" links are selected, 
the user may download related software (e.g., computer 
games, applications software or web originated soft- 
ware). For example, a "computer disk" button/link could 

45 be used for accessing the data catalogue of webcaster 
broadcasts, downloading software the next time it is 
broadcast, retrieving or purchasing software already 
cached, or for retrieving software over the network con- 
nection 122. "View" links could make a given picture 

so area active, "full" links may expand the associated 
video/picture area to occupy a substantial portion of the 
full screen, "record" links may use the broadcast time 
and channel information associated with a program to 
control a video recorder to record the program at its 

55 broadcast time, "buy" links may allow users to purchase 
pay-per-view programming or services via conventional 
impulse-pay-per-view purchase screens, for example, a 
"dollar sign" button/link could be used to launch an 
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impulse pay-per-view process for pay-per-view pro- 
grams. "Data-catalog" links could take the user to the 
webcaster broadcasting schedule for the system. A 
"lock" link could be used for controlling access to pro- 
grams, for example by limiting movies to no higher than 
a PG-13 rating (ratings information is obtained from the 
grid-guide datastream). A "star" link could be selected 
to bring up a list of the cast in the current show. A "video 
tape" link could be used to launch aulomatic VCR pro- 
gramming by accessing the channel and time informa- 
tion from the grid-guide datastream and using that 
information to control the recording features of the VCR 
1 36. A "checkbox" button/link could be used to add to a 
list of favorites stations or to configure a viewing 
agenda. A "question mark" button/link could be used for 
displaying additional information associated with the 
program, such as times, ratings, and a lextual synopsis. 
Thus, the various links may be selected and activated 
by the user to launch the PPG between various states 
or pages. Of course, there are many other links and 
associated actions that could be provided. 
[0047] In accordance with the present invention, a 
time line 236 may be provided adjacent to one or more 
of the active video areas 228. The time line 236 may 
indicate the progress of the currently running program. 
For example, the ends of the time line 236 may repre- 
sent the respective start and finish times of the currently 
running program and a shaded portion of the time line 
236 may correspond to the time elapsed from the start 
time to the current time. Thus, a user may quickly deter- 
mine how much of a currently running program is avail- 
able for viewing before making a viewing 
selection/purchase. In some embodiments, the user 
may be prevented from buying a pay-per-view program, 
for example, if less than 50% of the program remains 1o 
be broadcast. 

[0048] In other embodiments, the time line 236 may 
be used to select a viewing time for a video/picture area. 
In these embodiments, scrolling back and forth in time is 
accomplished with arrow links, and jumping to a partic- 
ular time can be performed, for example, via a calendar 
(not shown) that pops up when a calendar link is 
selected. Of course, any time selection metaphor could 
be used. The current time is the default, however, going 
forward in time allows for agenda planning, VCR pro- 
gramming, etc. The video picture in the video area auto- 
matically changes to the pictures appropriate for the 
requested guide time-frame. 

[0049] The current date and time are displayed in a 
date/time segment 238. Moving the display time for all 
of the video/picture areas at once could be accom- 
plished via a calendar or time bar or menu that could be 
accessed by, for example, double-clicking a mouse con- 
trol on the date/time segment 238. 
[0050] FIG. 4 illustrates, by way of example only, the 
"data" category template of one embodiment of the 
present invention. The video/picture segment 228 dis- 
play various data delivery services. For example, a 



NASDAQ service channel displays a stock ticker with 
recent stock symbols and prices, and a sports ticker 
shows scores for games currently being played. The 
data delivered by these services is updated periodically 

5 and scrolls across the various video/picture areas 238. 
Persons of ordinary skill in the art will appreciate that 
text, graphics, video, sound, and software can be com- 
bined in various combinations to deliver content associ- 
ated with data delivery services. For example, breaking 

w CNN news headlines with video/audio clips could be 
transmitted as file data and stored in a designated 
memory location of the PC 128. Viewer's are notified of 
the general nature of the story and the availability of the 
news clip by a scroll across the live video feed for CNN, 

is or by a pop-up "breaking news" link/button, or some 
other method. The viewer can access the video clip by 
clicking the button/link. Similarly, software (e.g., a game 
or new version of a spreadsheet application) could be 
requested and downloaded. 

20 [0051] At the bottom of each template 220 shown in 
FIGS. 2-4 are auxiliary areas 234. These areas can be 
used in a variety of ways, such as for additional tem- 
plates/buttons, advertisements, special messages, and 
other communications. These areas can also be used to 

25 allow various PPG services and/or operations to be 
launched withoul having to alter the basic template 
presentation. For example, if an impulse pay-per-view 
operation is initiated, the purchase screens from the 
grid-guide datastream could be displayed in the auxil- 

30 iary areas 234 instead of the video area for that channel 
or the full screen, thereby allowing the purchase to pro- 
ceed while still viewing the basic PPG template. Or, if a 
software game associated with the channel is down- 
loaded, it can be launched and run in the auxiliary areas 

35 without having to exit the current PPG template. 

[0052] FIG. 5 shows one example of a box occupy- 
ing the video/picture segment 220 where enlarged live 
video or a web page are displayed in response to the 
selection of the "Full" or "Web" buttons respectively. In 

40 the present embodiment the active video segment 222 
can be replaced with a logo associated with the current 
channel or web page, and the category segment 226 
lists web pages associated with the current category. A 
"category" button/link under the active video/audio seg- 

45 ment 222 allows the user to return the category seg- 
ment 226 to a list of categories, thereby allowing the 
user to return the screen to a particular category tem- 
plate. 

so III. Receiver Station Generally 

[0053] As noted above, Ihe PPG of the present 
invention is preferably implemented within a DTH PC- 
based satellite communication system 100 such as that 
55 depicted generally in FIG. 1. Discussed in more detail 
below is a preferred system and method for executing 
the PPG software of the present invention. In particular, 
a preferred receiver station 106 architecture is dis- 
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closed. In addition, preferred data transmission meth- 
ods that facilitate the PPG's ability to receive and 
manage the large amount and variety of digital informa- 
tion that is broadcast within the DTH system 1 00 are 
disclosed. $ 
[0054] FIG. 6 is a detailed illustration of a preferred 
implementation ol the receiver station 106 shown in 
FIG. 1. As shown, the receiver station 106 includes the 
reception antenna 124, the LNB 126, and the PC 128. 
The PC 128 includes the monitor 1 30 and the comput- io 
ing unit 132, which may have a modem connection via 
the PSTN to the network 122. The computing unit 132 
includes, inter alia, a satellite receiver card 418, a 
video/audio decoder card 420, which may be integrated 
with the receiver card 418, a conditional access card is 
422, a mass memory such as a hard disk (not shown), 
and processing/control capabilities such as a PC moth- 
erboard 424. The satellite receiver card 418 includes a 
tuner 426, a demodulator 428, a forward error correc- 
tion (FEC) decoder 430, and a transport functional 20 
processing block 432. The video/audio decoder card 
420 includes a video/audio decoder 434, an optional 
NTSC and/or ATSC output driver 438, and a VGA output 
driver 436. The satellite receiver card 418 and 
video/audio circuits (e.g., video/audio decoder card 25 
420) perform the functions of receiving and decoding 
the signal received from the LNB 126. The incoming sig- 
nal is received by a satellite receiver card 418 and 
passed through a series of initial processing operations 
including the tuner 426, the demodulator 428, and the 30 
forward error correction decoder 430, before passing to 
the actual transport functional processing block 432. 
Although the functional circuits within the transport 
functional processing block 432 are not illustrated, they 
are identical to the channel demultiplexing, decryption, 35 
and access determination circuil blocks of a standard 
transport decoder. For example, the transport functional 
processing block 432 receives the transport stream or 
bitstream of digitized data packets containing video, 
audio, scheduling information, and other data. The dig- 40 
ital packet information contains identifying headers as 
part of its overhead data. Under control of the PC's main 
processor/controller (typically located on the PC moth- 
erboard 424), the transport functional processing block 
432 filters out received data packets that are not cur- 45 
rently of interest. Received data packets that are of 
interest are routed through decryption and access con- 
trol operations within the conditional access card 422. 
Access control may be provided by any known means. 
For example, access control may be achieved by requir- so 
ing a data packet to have a proper authorization code in 
order to be passed to the video/audio decoder card 420. 
[0055] The transport functional processing block 
432 passes the data to the video/audio decoder 434 of 
the video/audio decoder card 420. The authorized data 55 
of interest are stored in system RAM (not shown) lor 
buffering, and the video/audio decoder 434 retrieves the 
data from RAM as needed. 



[0056] The allocation of memory and control func- 
tions may be arbitrarily divided between the PC sys- 
tem's function cards (e.g., the satellite receiver card 
418, the video/audio decoder card 420, etc.). Thus, a 
substantial amount, or possibly all, of the control and 
memory functions for operation of the present invention 
may be integrated within a single card, or alternatively, 
may be incorporated within the PC motherboard 424. 
When needed, the data is routed to Ihe video/audio 
decoder 434, which includes display circuitry. For video 
data, the video/audio decoder 434 reads in the com- 
pressed video data from its RAM, parses it, creates 
quantized frequency domain coefficients, then performs 
an inverse quantization, inverse discrete cosine trans- 
form (DCT) and motion compensation. At this point, an 
image has been reconstructed in the spatial domain. 
This image is then stored in a frame buffer in the video 
decoder's RAM. At a later time, the image is read out of 
the frame buffer and passed through the display cir- 
cuitry to the VGA output driver 436 and optionally, to the 
NTSC and/or ATSC output driver 438. The display cir- 
cuitry also generates the graphics that allow text such 
as the PPG electronic program grid guide data to be dis- 
played. 

IV. Receiver Station Architecture 

[0057] Illustrated in FIG. 7 is a system architecture 
block diagram 500 depicting, by way of example only, a 
preferred organization of the PC's computing unit hard- 
ware and software which may implement aspects of the 
present invention. A tuner driver 502, a TV control block 
504, a video MPEG driver 506, and a video VGA driver 
508 provide the major functions of a conventional inte- 
grated receiver decoder (IRD). The tuner driver 502 
receives a digital signal modulated on an RF carrier 
(e.g., a digital satellite downlink signal) on line 510, and 
performs known IRD functions to parse out and selec- 
tively control the flow of conditional access, video/audio, 
and MPT data streams. The tuner driver 502 passes 
selected video/audio data packets to the video MPEG 
driver 506 on line 512. The MPEG driver 506 controls 
the MPEG decoding hardware, synchronizes video and 
audio data, and manages the buffering of video and 
audio data to be displayed. The MPEG driver 506 
passes decoded video information to the video VGA 
driver 508 via line 516. The VGA driver 508 processes 
the decoded video information 514 and provides a dis- 
play signal that may be, for example, a standard RGB 
output on line 51 6. The TV control block 504 controls 
the size and location of the video window via an MPEG 
decode control signal on line 518 and a VGA window 
display control signal on line 520 that are passed to the 
video MPEG driver 506 and the video VGA driver 508 
respectively. 

[0058] With respect to file data, the tuner driver 502 
passes file data (e.g., websites, software, etc.) as MPT 
data packets to a tuner NDIS driver 522. The NDIS 
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driver 522 strips the MPT header and passes standard 
IP data packets 524 using Microsoft® NDIS protocol 1o 
a standard Windows® Winsock® interlace 526. File 
data 528 may alternatively be passed to the Winsock® 
interface 526 as IP data packets via a network driver 
530 that exchanges information with a network connec- 
tion 532 thai may, for example, be an Ethernet, ISDN, or 
POTS connection. 

[0059] A data manager 534 functions as a data dis- 
tributor or data hub. The data manager 534 receives 
and interprets file data from line 536. The data manager 
534 further provides an optional HTTP proxy service via 
line 538, uses an SDP + data store 540, and schedules 
data-related tuning requirements. The data manager 
534 may store data files (e.g., HTML, GIF, etc.) on a 
local file system 541 (e.g., a hard disk) via a fifth data 
path 542. 

[0060] The data manager 534 may use a TAPI 
library block 546 to communicate via a telephony appli- 
cation programming interface (TAPI) via line 544. The 
TAPI library block 546 is in direct communication with a 
modem 548 having a POTS phone line connection 550. 
In this way, the data manager 534 can report to a serv- 
ice provider which advertisements a particular user has 
viewed or selected (i.e., advertisement tracking). In 
addition, the data manager 534 communicates with a 
service/CA manager 552, which sets tuning priori- 
ties/controls, manages conditional access messages, 
and resolves messages relating to program tuning infor- 
mation that are exchanged via a third data path 554 
to/from the tuner driver block 502. 
[0061] The SDP + data store 540 is a database that 
contains all the current SDP + record information. The 
SDP + data store 540 passes DPG data store queries 
for data item description and display formatting informa- 
tion to a data program guide block 558 on line 556. The 
data program guide block 558 contains the dynamic 
HTML pages, including graphic content, that is currently 
being broadcast by the satellite communication system 
100. The data program guide block 558 may retrieve 
files from the local file system 541 via a fourth data path 
560. The SDP + data store 540 may also pass enriched 
TV dala store queries 562 to an enriched TV function 
564 that serves to map a channel to an IP address and 
a port. The enriched TV function 564 may further 
receive tuning control information, via line 566, from a 
tuning control interface 504 and may, accordingly, pass 
screen formatting information to the TV control block 
504 on line 570. The enriched TV function 564 and the 
data program guide block 558 may exchange informa- 
tion with a browser application 572 along a first dala 
path 574 and a second data path 576, respectively. 
[0062] As described in section II of this disclosure, a 
user may interact with the PPG to invoke the download 
of file data (e.g., by selecting various "software" links). 
The PPG utilizes SDP+ records to perform this task. 
The SDP + records are stored in the SDP + data store 
540. At the scheduled time of reception, the data man- 



ager 534, which holds schedule information, examines 
the records in the SDP + data store 540 to determine 
the multicast IP address on which the download will be 
broadcast. After the data manager 534 has determined 

5 the multicast IP address, the service manager 552 looks 
to the BARP table, which may be stored on the local file 
system 541 , to determine tuning information for the mul- 
ticast IP address found in the SDP+ record. For exam- 
ple, a broadcast of Quicken '98™ software may be 

w broadcast on multicasl IP address 1 .2.3.4 and that mul- 
ticast IP address may correspond to tuning information 
indicating transponder two SCID five, according to the 
BARP table. Once the tuning information is determined, 
it is passed to the service/CA manager 552, which 

(s tunes the tuner driver 502 to, for example, transponder 
two, SCID five. 

[0063] File information received by the tuner 502 is 
passed to the tuner NDIS driver 522, where it is con- 
verted into IP data and passed to the Winsock® 526, via 

20 line 524. The Winsock®, in turn, passes the IP data to 
the data manager 534, which performs the BFDP func- 
tion on the IP data to recover the data for Quicken '98™. 
The data associated with Quicken '98™ is stored on the 
local file system 541 for later use. Any data determined 

25 by BFDP to be missing from Ihe received Quicken '98™ 
file will be obtained on subsequent broadcasts of the 
file. When the complete file has been stored on the local 
file system 541 , Quicken '98™ is complete and ready to 
run. 

30 

V. Data Packets 

[0064] FIG. 8 is a diagram illustrating a preferred 
type of transport data packet that may be transmitted via 

35 the system 100 shown in FIG. 1 and processed by the 
receiver station 106 shown in FIGS. 22 and 23. More 
specifically, the data packet may be coupled to the 
receiver station shown in FIG. 7 via line 510. The pre- 
ferred data packet shown in FIG. 8 is in the format and 

40 of the type used in the DirecTV® digital broadcast sys- 
tem. As shown, each data packet may be, for example, 
1 47 bytes long. The first two bytes (a byte is made up of 
8 bits) of information contain the SCID and flags. As 
previously stated, the SCID (service channel ID) is a 

45 unique 12-bit number that uniquely identifies the 
packet's service channel. The flags are made up of four 
bits used primarily to control whether or not the packet 
is encrypted and, if encrypted, which key to use to 
decrypt the packet. The third byte of information is 

so made up of a four-bit packet type indicator and a four-bit 
continuity counter. The next 127 bytes of information 
consists of the "payload" data, which is the actual usa- 
ble information sent from the program provider. The 
payload can be any of the various types of data sent 

55 over the airlink, including video, audio, conventional pro- 
gram guide data, data related to the layout/format/con- 
tent of the template pages of the present invention, 
conditional access data, webcasting data, software 
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download data, etc. 

VI. Audio/Video Processing 

[0065] The architecture shown in FIG. 7 may be 
used to receive audio and video signals associated with 
television programming. When a user desires to walch 
television programming, the service/CA manager 552 
tunes the tuner driver 502 to the appropriate trans- 
ponder and SCID or SCIDs to receive the appropriate 
programming signals. The received signals are passed 
to the MPEG video driver 506 via line 512. The MPEG 
video driver 506 appropriately processes the received 
signals to obtain audio and video signals that are 
passed to the video VGA driver 508, which, in turn, 
passes the signals to a monitor for display. 

VII. Data Processing 

A. Protocol Stack/Broadcast File Download Protocol 
(BFDP1 

[0066] As discussed in section I of this disclosure, 
the PPG of the present invention requires the presence 
ol appropriate data at the receiver station 106. Allhough 
a variely of data processing techniques could be used in 
conjunction with the PPG of the present invention, 
BFDP, BARP, and SDP + are exemplary of preferred 
data processing methods. Respectively, these methods 
provide a way of reliably transferring file data in a one- 
way communication channel, resolving IP addresses 
into physical addresses, and announcing to the receiver 
station 106 how to display available data streams for 
selection, and when and how to tune to data streams 
selected by the user. 

[0067] Illustrated in FIG. 9, is a preferred data flow 
through a protocol stack that utilizes the BFDP, BARP, 
and SDP + data processing methods. The transmission 
station 1 02 (or "headend") builds transport data packets 
for transmission in accordance with the headend data 
flow arrow. There are four primary data flow paths 
through the protocol stack at the transmission station 
102. File data begins at an application layer 602 and is 
passed down through a BFDP layer 604, a UDP layer 
608, an IP layer 610, and is encapsulated for transmis- 
sion to the receiver station 1 06 by an MPT layer 614 and 
a transport layer 616. Webcast data begins at the appli- 
cation layer 602 and is passed down through a webcast 
layer 603, the BFDP layer 604, the UDP layer 608, the 
IP layer 610, the MPT layer 614, and the transport layer 
616. SDP+ records begin at the application layer 602 
and are passed down through an SDP + layer 606, the 
UDP layer 608, the IP layer 610, the MPT layer 614 and 
the transport layer 616. BARP information begins at the 
application layer 602 and is passed down through a 
BARP layer 612, the MPT layer 614- and the transport 
layer 616. Transport packets received at the receiver 
station 106 (or "subscriber") are resolved into BARP 



information, SDP + records, webcast information, and 
file data by passing the received packets up through the 
protocol stack in the direction indicated by the sub- 
scriber data flow arrow. 

s [0068] Illustrated in FIG. 1 0 is an exemplary method 
of processing a data packet using the protocol stack 
shown in FIG. 9. FIGS. 9 and 10 are described is more 
detail below in connection with in-depth discussions 
regarding the BFDP, BARP, and SDP + data processing 

J c methods. 

[0069] Downloading file data is especially difficult 
within the DTH system 100 (shown in FIG. 1) because 
the DTH system 100 does not provide a backchannel 
communication path from the receiver station 1 06 to the 

is transmission station 102 (i.e., the communication path 
is a one-way path to the receiver station 106). The 
absence of a backchannel makes it impossible for the 
receiver station 1 06 to acknowledge to the transmission 
station 102 that a software file was completely received 

20 and error free. Additionally, the absence of a backchan- 
nel prevents the receiver station 106 from requesting 
rebroadcast of missing data from the transmission sta- 
tion 102. Although the communication channel associ- 
ated with the DTH system 100 has a very low bit error 

25 rate, relatively long periods of signal interruption may 
occur. For example, snow or rain, either at the transmis- 
sion station 102 or the receiver station 106 may cause 
the communication channels of the system 100 to fade, 
thereby causing received signal errors. Additionally, 

30 user activity, such as receiver station tuning or deactiva- 
tion, may cause signal interruptions. If signal interrup- 
tions occur during the download of file data, the file data 
will be incomplete and inoperable. 
[0070] One preferred method of addressing the dif- 

35 ficulty associated with transmitting file data along a one- 
way communication path, such aslhat used by the PPG 
of the present invention, uses data carousels at the 
transmission station 102 that repeatedly broadcast the 
same file data to the receiver station 106 in conjunction 

40 with a data transfer protocol that is the subject of a co- 
pending, commonly assigned patent application serial 

no. filed on and 

entitled . The Broadcast File 

Download Protocol (BFDP) prepends a header to the 

45 file before transmission of the data packets. This header 
allows a download file to be reassembled from informa- 
tion received during one or more broadcasts of the 
same download file. Thus, if some file data is lost or cor- 
rupted during a first broadcast of the download file, 

so BFDP allows the receiver station 106 to "fill in" any 
missing or corrupted file data with file data received dur- 
ing a subsequent broadcast of the same download file, 
thereby avoiding the constraint of having to receive an 
entire file without corruption/interruption during a single 

55 broadcast. 

[0071] The details of BFDP will now be explained 
with reference to FIGS. 9 and 10. If a file (e.g., a web- 
site, a software file, etc.) is to be broadcast from the 
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transmission station 102 to the receiver station 106, 
data from the application layer 602, such as webcast, is 
passed to the BFDP layer 604. For purposes of expla- 
nation of the BFDP, it will be assumed that a data file 
620 having 2 kilobytes (2K) of data is to be transmitted. 
The data file 620 is received by the BFDP layer 604, 
which if necessary, breaks the data file 620 into smaller 
data fragments 622 and 624. For purposes of explana- 
tion it is assumed that the data file 620 is split into two 
1K data fragments 622, 624 and thai a BFDP header 
626 is prepended to each of the data fragments 622, 
624. The size of the fragments is a tradeoff between 
overhead and the probability of data loss. If low over- 
head is desired, the size of the data packet will be large 
with respect to the BFDP header on the data. However, 
if the probability of data loss is high, the size of the data 
packets should be made small to minimize the data lost 
if a single packet is lost. Typically, Ihe probability of dala 
loss is determined by channel characteristics. The 
remainder ol the processing for each fragment is identi- 
cal. A sample format for the BFDP header 626 is shown 
in FIG. 11. 

[0072] The eight fields of the sample BFDP header 
626 provide information concerning the number and 
order o( the data fragments 622, 624 that are broadcast 
to make up the data file 620. Each field in the sample 
BFDP header 626 is represented by four bytes, except 
for filename, which is represented by sixty-four bytes. 
The Sync, field contains information that may be used to 
assist in identifying the header. An ID field is a represen- 
tation of the object ID for the file being broadcast. The 
object ID may be used for dala filtering at the receiver 
station 106. The Version field indicates the version of 
the BFDP used to create the present packet. Filename 
is sixty-four bytes ol information used to indicate the 
filename and path where the data fragment is to be 
stored on the receiver station 106 (e.g., C:\down- 
loads\xyz). Preferably, the filename field is used only for 
special files and is not generally used. For example, 
when webcast information is transferred, a HTTP 
header is used and the filename field is ignored. The 
Modified field denotes the last time the fragment was 
modified. Preferably, this representation is in UNIX 
timej format. Count, Number, and Size fields refer to 
the number of fragments used to make up the original 
file data that is broadcast, the number of this fragment, 
and the size of this fragment, respectively. The count, 
number, and size fields are key pieces of information 
that allow BFDP 1o reconstruct a complete data file from 
multiple broadcasts of the data file. For example, a data 
file may be broken into 10 fragments and, during trans- 
mission, fragments 1-5 and 8-10 were received by the 
receiver station 106. On subsequent broadcasts of the 
data file, the receiver station 106 examines all of the 
BFDP headers on the received fragments and only 
stores the data packets indicated as fragments 6 and 7 
in their BFDP headers, thereby filling in the received 
data file. 



[0073] As shown in FIGS. 9 and 10, after the 
processing is complete at the BFDP layer 604, the 
resulting data packet is transferred to a UDP layer 608, 
which prepends a UDP header 628 to the packet. The 

5 UDP header 628, which is standard and well known in 
the art, is shown in FIG. 12. The UPD header 628 
includes fields that denote source and destination ports 
for the data. That is, UDP header fields contain informa- 
tion indicating the application that is providing the data 

w (source port) and the application that is to receive the 
data (destination port). At this point in the processing, 
the data packet is referred to as a UDP packet 630. 
[0074] Data transferred to a computer through a 
connection is typically in an Internet protocol (IP) for- 

15 mat, which is well known to those skilled in the art. 
Accordingly, the UDP packet 630 is passed to the IP 
layer 610, which in a well known manner, prepends an 
IP header 632 onto the UDP packet 630, thereby creat- 
ing an IP packet 634. The IP header 632, which is 

20 shown in FIG. 13 denotes, inter alia, the IP addresses of 
the data source and destination computers. Information 
that is broadcast to a number of users preferably uses a 
multicast IP address. Alternatively, information may be 
addressed to specific users via a standard IP address. 

25 [0075] After the UDP packet 630 has been properly 
processed by the IP layer 610 to create the IP packet 
634, the IP packet 634 is passed to an MPT layer 614. 
The MPT layer 614 processes the IP packet 634 to cre- 
ate an appropriate number of MPT packets 636. For 

30 example, in digital video broadcasts (DVB) the size of 
the MPT packets may be 185 bytes. Alternatively, the 
MPT packets may be 127 bytes long for other direct to 
home (DTH) applications. For use in the present system 
20, each the MPT packets 636 is 127 bytes long includ- 

35 ing a header and data. The MPT layer uses a number of 
packet configurations, shown in FIGS. 1 4A - 1 4D, to cre- 
ate the 127 byte packets. If the IP packet 634 contains 
1 14 bytes or less, only one MPT packet referred to as an 
"Only Packet" 760 needs to be created. The preferred 

40 format of the Only MPT packet 760 is shown in FIG. 
1 4D. The Only packet 760 includes: a six bit flag field 
that is preferably reserved and set to all zeros, a one bit 
start of frame (SOF) field that indicates that this packet 
is the start of the frame, a one bit end of frame (EOF) 

45 field that indicates that this packet is the end of the 
frame. If the IP packet 634 contains 114 bytes or less, 
only one MPT packet 636 will be sent, therefore the 
Only packet header indicates that the Only packet 760 
is the start of the frame and the end of the frame. The 

so Only packet 760 may also include a field indicating the 
sub-SCID address of the packel, which preferably 
includes a two byte type code and a four byte type- 
dependent code. Preferably, the type code is 0x0100, 
which signifies that the last four bytes are the multicast 

55 group address to which this frame belongs. The Only 
packet 760 may also include a frame type field, which 
identifies the type of content in the MPT frame. Prefera- 
bly, this field is used to indicate whether the frame is an 
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IP frame or a BARP frame. Preferably, the frame type 
field is filled using Internet Assigned Number Authority 
(IANA) standard numbers. Further, the Only packet 760 
may include a cyclic redundancy check (CRC), which is 
a 32-bit number computed over the entire MPT frame. 
[0076] If th e I P packet 634 is to be processed by th e 
MPT layer 614 is longer than 1 14 bytes, Start 730, Mid- 
dle 740, and End 750 MPT packets shown in FIGS. 14A 
- 14D are preferably used to process the IP packet 634. 
The headers of these packets use all combinations of 
the fields described in conjunction with the Only packet 
760. As shown in FIG. 10, the first 118 bytes of the IP 
packet 634 are loaded into the MPT Start packet 730. 
The start header of the MPT packet denotes a MPT 
packet as the start of the frame by setting the SOF bit. If 
the IP packet 634 is larger than 244 bytes the appropri- 
ate number of Middle packets 740 will be filled with 126 
byte sections of data from the IP packet 634. The SOF 
and EOF bits will not be set because the MPT packet is 
a middle packet. Numerous middle packets will be filled 
with the IP data until there is less than 1 22 bytes of data 
remaining in the IP packet 634. At this point an End 
packet 750, is filled with the last bytes of information and 
appended with a CRC. This method of using Only, Start, 
Middle, and End packets yields MPT packets that are all 
exactly 1 27 bytes long. 

[0077] After each IP packet 634 has been con- 
verted to one of the MPT packets 636, each of the MPT 
packets 636 is passed to the transport layer 616. The 
transport layer 61 6 places each 127 byte packet into the 
127 byte payload section of a transport data packet 
(shown in FIG. 8). The complete transport data packet 
is passed to the uplink frequency converter 1 18 of FIG. 
1 and broadcast to the receiver station 106. 
[0078] As the receiver station 106, which istunedto 
a particular transponder and SCID, receives packets of 
information, the data packets traverse up through the 
protocol stack as indicated by the subscriber data flow 
indicated on FIG. 9. The transport layer removes the 
payload from each transport packet. After the appropri- 
ate processing, the payload is passed to the MPT layer 
614, which strips the MPT header from the packet and 
assembles all relevant data from MPT packets to 
assemble the IP data frame. The IP layer 610 strips the 
IP header 632 from the data, performs well-known IP 
processing functions, and routes the data to the UDP 
layer 608. The UDP layer 608 strips off the UDP header 
628 and routes the remaining information to the proper 
application (port) as denoted by the UDP header. The 
BFDP layer 604 strips the BFDP header 626 from the 
data packets and, using the information in the headers, 
reassembles the data contained in the BFDP packets 
into the data file 620 as sent by the transmission station 
102. Additionally, if necessary, the receiver station 106 
denotes missing data packets through examination of 
the BFDP headers. Thus, the PPG of the present inven- 
tion may reassemble the original data file in accordance 
with the BFDP header fields at the receiver station 106 



after multiple broadcasts of the original data file. That is, 
any missing data after the dala is broadcast will be 
"filled in" with the appropriate data from subsequent 
broadcasts of the original data a file. For example, if a 1 

s megabyte (MB) file is broadcast and the receiver station 
106 successfully acquires all but 1 kilobyte (KB) of the 
broadcast information, instead of having to reacquire all 
of the data that the receiver station 106 has already 
received, the receiver station 106 simply waits for and 

io acquires the 1 KB of data that it needs to complete the 1 
MB file. 

B. Broadcast Address Resolution Protocol (BARP) 

is [0079] As referenced earlier, the broadcast address 
resolution protocol (BARP) layer 612 is required to 
resolve IP addresses into physical (i.e., satellite trans- 
port) addresses. BARP is the subject of a co-pending 
commonly assigned application entitled 

20 filed on and bear- 
ing serial no. I . The BARP layer 

is coupled to the MPT layer 614 and is used to map a 
multicast source IP address to transport-specific tuning 
information. That is, BARP is a map that tells a receiver 

25 station 106 on which transponder or transponders and 
SCID or SCIDs, information from a particular source IP 
address may be found. For example, when a user 
selects information from the PPG, the receiver station 
106 uses BARP to determine tuning parameters (e.g., 

30 transponder and SCID) for the information selected by 
the user. Preferably, BARP information is periodically 
sent on as many transponders as possible so that users 
have easy access to the most current BARP informa- 
tion. 

35 [0080] BARP consists of a header followed by zero 
or more address records. BARP preferably uses MPT 
frame type 0x0806. FIGS. 15A and 15B represent the 
format of a BARP header and a BARP address record, 
respectively. The BARP header includes version, 

40 change number, record count and reserved fields. In 
this example, version is a 1 byte field that represents the 
version of the BARP format used to create the header 
and address record. Change number is a 1 byte field 
that is incremented each time anything in the header or 

45 any of the address records change. Record count is a 2 
byte field that indicates the number of address records 
that follow this BARP header. The reserved field is a 
four byte field that may be used to provide system flexi- 
bility in the future. 

so [0081] The BARP address record, as shown in FIG. 
15B, includes six fields. An IP address field contains a 
four byte representation of an IP address. Transponder 
is a bitmap field identifying the transponders on which 
the previously-noted IP address can be found. Each bit 

55 in the transponder field corresponds to a transponder. 
Set bits in the transponder field indicate the presence of 
the IP address on that transponder. For example, if the 
first bit is set (1) and the rest of the bits are clear (0) then 
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the IP address listed in the IP address field is present 
only on the first transponder of the system. The SCID 
field denotes the 12 bit SCID that contains the informa- 
tion provided by the IP address listed in the first field of 
the header. Preferably, the four most significant bits are 
reserved. Channel is 10-bit channel number that is 
associated with the this SCID and transponder. For 
example, transponder two, SCID nine may correspond 
to channel 105. Preferably, Ihe most significant 6 bits of 
the channel field are reserved for future use. Service 
type is the type and paradigm of the channel associated 
with the transponder and SCID in the address record. 
The reserved field is 3 bytes long and is preferably 
reserved for future system use. Information lor channel 
and service type fields are preferably supplied by the 
broadcaster to satisfy tuning requirements of subscriber 
units. 

[0082] While the BARP and BFDP protocol layers 
represent one preferred way of transmitting the informa- 
tion related to the PPG of the present invention, other 
transmission systems and methods may be substituted 
without departing from the spirit of the invention. 

C. SDP+ Records 

[0083] Another difficulty faced in utilizing Ihe wide 
variety and large amount of information transmitted 
within the DTH system 100 is providing a way for the 
PPG to efficiently find and process the various kinds of 
data that are available at various times within the multi- 
program data stream. One preferred method that allows 
the PPG of the present invention to efficiently find and 
process information for presentation to a user are "ses- 
sion description protocol plus" (SDP+) records. SDP+ 
records are the subject of a co-pending commonly 

assigned application entitled , 

filed on and bearing serial no. 

__! . 

[0084] An SDP + record is an announcement mech- 
anism that includes a number of fields, which are 
assembled into a single record or file to provide informa- 
tion on available services such as webcasts, down- 
loads, and streaming data or other services. The SDP + 
protocol is a combination of standard SDP fields and 
augmentations, or extensions, to the standard SDP pro- 
tocol. Additional details regarding the standard SDP 
protocol may be found in RFC 2327. The standard fields 
of the SDP protocol that are used in the of the SDP + 
protocol include, protocol version, the owner/creator 
and session identifier (i.e., the IP address of the creator 
of the SDP record), the name of the SDP session (i.e., 
the name of the SDP record), a brief description of the 
session (i.e., what the SDP record is for), the multicast 
address on which the session is being broadcast, the 
start and end times of the broadcast, the repeat times of 
the broadcast, a list of Internet webpages that can pro- 
vide additional information on the item that is going 1o 
be broadcast, what the port of the broadcast is (i.e., the 



UDP port of the broadcast), the type of broadcast (e.g., 
BFDP, Stream, Webcast or Intercast), sorting and filter- 
ing information. 

[0085] As noted, an SDP + record may also contain 

5 information such as the time a particular service will be 
broadcast, the multicast IP address on which the serv- 
ice will be broadcast, the size of the file that will be 
broadcast, and information relevant to the PPG such as 
text or images that should be displayed to the user. 

10 Each download service (e.g., each webcast, each soft- 
ware download, etc.) has its own SDP+ record, which is 
broadcast to all subscribers to inform them of the infor- 
mation that is available for download. With reference to 
PPG information, SDP + records are used by the PC 

is 1 28 to build particular sections of pages using selected 
information resident within the PC 128 (e.g., the basic 
page templates shown in FIGS. 2-5) and selected 
dynamic data that is received from a satellite in the form 
of SDP + records. When the user launches the interface 

20 into another state or page, the PPG builds the destina- 
tion page as instructed by the templates and by the SDP 
+ records. The page is then displayed on the user's PC 
monitor 130. 

[0086] SDP + records also allow users to pre-select 
25 download content from descriptions of the content, then 
filter for that information as it arrives in the one-way data 
stream of the DTH system 100. The descriptions of the 
content may include extended SDP records including 
protocol version, name, times of broadcast, IP address, 
30 mandatory download status, ID number, run command, 
category, file size, text messages, channel, images, 
keywords, etc. 

[0087] As previously mentioned, SDP + records 
also provide announcement information including con- 

35 tent type, start time, duration, Internet address informa- 
tion, and actions to be taken on receipt of the 
information. Announcement management is critical to 
finding the data stream, discrete download or webcast 
information in the received transmission. SDP + records 

40 can be rescinded and modified, once they are present 
on the user's PC 128. SDP+ records can be used to 
indicate mandatory download events such as software 
updates. The system user (client) uses SDP + records 
to schedule program reception. After the client makes 

45 selections based on the SDP + record information, the 
receiver station 106 properly tunes itself to receive the 
selected information. 

[0088] SDP + records are a combination of conven- 
tional SDP records and extensions to the conventional 

so SDP records. Generally, the extensions to the standard 
SDP protocol consist of fields for linking different down- 
load services together, specifying if a download file is 
mandatory, archived or should be run upon download to 
the receiver station 1 06. The extensions also provide for 

55 specification and placement of graphics for the PPG, 
the notification of the user upon receipt of the SDP + 
record, and the recission of previously sent SDP + 
records. These unique extensions coupled with the 
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standard SDP protocol yield the SDP + protocol used in 
conjunction with Ihe PPG of the present invention. The 
details of the conventional SDP fields and the unique 
extensions of the present invention are best described 
in conjunction with the exemplary SDP+ records shown 
in FIGS. 16A-16D. 

[0089] Referring now to FIGS. 16A-16D, fields indi- 
cating version (v), record ID (o), multicast IP address 
(c), time (t), and port (m) are required for all SDP+ 
records of any kind. Additionally, for any BFDP down- 
load the object ID BFDP code (a=key:) is needed. The 
run command (a = run:) is required lor all streaming 
data downloads. For all streams having an entry in the 
MPG a channel link (a = channel) is required. Addition- 
ally, for all webcasts a URI address field (u = < uri > ) is 
required. 

[0090] FIG. 16A is a sample SDP + record lor 
streaming data, which is commonly referred to as a 
ticker. The field "v = 0" refers to the version of the SDP 
+ protocol used to produce this SDP + record. The 
record ID, which is represented by "o," indicates the 
unique session ID for this particular record. Specifically, 
the session ID for this SDP+ record is 0001 and the ver- 
sion of this record is 1 7. The session ID is a way to refer 
to this particular SDP + record and 17 indicates that 
there have been 16 previous versions of this SDP + 
record before this version. The name of this session is 
represented by "s= Announcement Dump." However, it 
should be noted that the session name is arbitrary 
ASCII text that is used to identify the SDP + record. The 
field "c" represents the multicast IP address of this ses- 
sion and 71" indicates that the Time To Live (TTL) 
value, which indicates the number of "hops" that a 
packet may make before it expires. Multicast IP 
addresses denote the IP address on which the informa- 
tion corresponding to the SDP + record will be broad- 
cast. The multicast IP address is used in conjunction 
with the previously described BARP table to tune a sub- 
scriber's receiver station 106 to the appropriate trans- 
ponder and SCID to receive the broadcast information. 
When a user makes a request to receive broadcast 
information using the PPG, the receiver station 106 
determines the multicast IP address on which the infor- 
mation will be broadcast by looking to the SDP + record 
corresponding to the selection. Once the multicast IP 
address is determined, the receiver station 106 uses the 
BARP table to correlate the multicast IP address to a 
transponder and SCID. The receiver then appropriately 
tunes itself to the proper transponder and SCID to 
receive the broadcast information. Since streaming data 
or tickers are always running, the start and end times 
represented by "t = 0 0" indicate that the data service is 
constantly running and is permanent. The field "m =" 
indicates that the UDP port of the data is 3278 and the 
type of data is streaming data. 
[0091] The SDP+ record shown in FIG. 16A 
includes "a=key:1 ," which indicates that the object ID for 
this SDP + record is 1. The object ID may be used for 



sorting or other functions. The object ID in the SDP + 
record matches the object ID sent in the BFDP header. 
The field "a = run: consoleticker" indicates that when the 
download is complete, an executable file named conso- 

s leticker should be started. The standard SDP field "a = 
keywds" is used to correlate SDP records to one 
another. For example, in the SDP + record shown in 
FIG. 16A "tselup" is used to correlate this SDP + record 
with another SDP + record, such as a client download 

10 file. 

[0092] FIG. 16B is an example SDP+ record for a 
file download. Similar to the ticker SDP+ record of FIG. 
16A, the file download SDP+ record a file download 
specifies the version of the SDP + protocol used to pro- 
is duce the SDP + record, the record ID, the name of the 
session, the multicast IP address of the session, and 
the object ID of the session. Additionally, the SDP+ 
record shown in FIG. 16B specifies download times 
using a "t= 3079382400 3155745600," wherein the first 
20 number is the start time of the broadcast and the sec- 
ond number is the end time of the broadcast. The start 
and end times are specified in decimal network time 
protocol (NTP) format. The "r = 10m 10m 0" specifies 
the broadcast repetition of the broadcasts, wherein the 
25 first number indicates the interval between broadcasts, 
the second number indicates the duration of the broad- 
casts and the third number indicates the time offset 
between the broadcasts. The field "m = " indicates that 
the UDP port of the data is 3335 and the type of data is 
30 BFDP data. The SDP+ record shown in FIG. 16B further 
specifies the size of the file that is to be downloaded 
using the "a =fsz" command. The example file download 
SDP+ record specifies afile size of 980K. The file down- 
load SDP + record also specifies that this file is a man- 
35 datory download using the command "a = mandatory." 
That is, Ihe receiver station must receive the data 
broadcast corresponding to this SDP + record during 
one of the broadcast times. The field "a = run:catalogin- 
stall.exe" specifies that after the data associated with 
40 the SDP + record is received, the file cataloginstall.exe 
must be executed. 

[0093] FIG. 16C is an example of an SDP+ record 
that is used to specify information pertinent to a web- 
cast. In addition to using the fields previously described 

45 in conjunction with the file download and ticker SDP + 
records, the webcast SDP + record may use the session 
description field denoted as "i = ." This field is an ASCII 
text field that may be used to describe the content of a 
particular session or webpage. The session description 

so field may be used as the program preview description 
represented as horizontal lines in a child window (not 
shown) that may pop-up when the system pointer rolls 
over a video image representing a program. Alterna- 
tively, the session description field of the SDP + record 

55 may be used in conjunction with SDP + records other 
than webcast SDP + records. The webcast SDP + 
record also includes afield denoting the URI of the web- 
page that is broadcast. The webcast SDP + record also 
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uses the standard SDP extension "a = cat," which is 
used for sorting and filtering the SDP + records. 
[0094] The webcast SDP + record uses the unique 
extension "a = display:type =" to indicate how the infor- 
mation content from the webcast will be displayed to the 
user. Additionally, the unique SDP+ field "a = img" is 
used to associate an image file (in this case cnn.gif) with 
a webcast. This image may be used as a thumbnail or 
any other representation of the content of the webcast. 
The image field and the display type field can work 
together to provide information for the PPG. Display 
type may be used to indicate on which page of the PPG 
the image specified in the image field must be placed. 
For example, type may be used to specify Movies, 
Sports, New, Data, or any other available category, 
each of which may be represented by a number. As 
shown in FIG 16C, type = 1 is specified, which may cor- 
respond to Movies. Accordingly the image cnn.gif will be 
placed on an appropriate page of the PPG as shown in 
FIG. 2. The specification of priority =8 denotes the par- 
ticular location in which the cnn.gif image will be placed 
on the page. Referring to the movies page shown in 
FIG. 2, different priorities correspond to different loca- 
tions in the arrangement of the images within the 
video/picture segment. 

[0095] FIG. 16D is an example of an SDP + record 
that may be used to represent enriched TV. In addition 
to the field discussed in conjunction with the SDP + 
records, this SDP + record includes the field "a = chan- 
nel." This field contains a 32-bit channel number that 
associates the data contained in the enriched video to 
channel content of a channel located in the program 
guide. The information contained in the enriched TV 
may be associated through a number of program guide 
channels. 

D. Webcast 

[0096] As previously noted, the DTH system 100 
broadcasts discrete downloads. These downloads are 
data items that have well-defined broadcast schedules 
and require detailed announcement information 1o 
locate the items in the received data. Examples of dis- 
crete downloads include software applications, such as 
spreadsheets, word processors or games. Webcasting 
is a special case of the discrete download. A webcast is 
an ongoing and repeating download of specially 
selected web content. The content is usually grouped 
by domain. Minimal scheduling is required for down- 
loading webcast information. Multiple groups of content 
may be identified by the same identifier, thereby creat- 
ing a one-to-many relationship among the items of inter- 
est. The system 100 may archive webpages pages on a 
the PC 128 for later viewing. 
[0097] As webpage information is received by the 
subscriber unit it is stored for later use. In the preferred 
embodiment, webpage information is received in a com- 
pressed format and is stored directly (i.e., without 



extraction) by the subscriber unit. Preferably, the 
present invention uses an archiving scheme based on 
the PKWare™ PKZIP™ format. However, other alterna- 
tive archiving formats may be used. If the archived files 

5 are compressed, the files are preferably exlracted on 
demand using a PKWare™ extractor. If, however, the 
files are not compressed, any ZIP extractor may be 
used to extract and view the files. Preferably, the filena- 
mes used in the webcast archive are actually the uni- 

w form resource identifier (URI). 

[0098] Preferably, webcast archive files have a ded- 
icated filename extension. On any given data carousel, 
the contents of which is repeatedly broadcast, there 
must be exactly one main file for each webcast. Prefer- 

15 ably, this file contains a snapshot of the entire websile or 
website subset as selected for broadcast. Update 
archive files may be used to replace portions of the 
main file on the carousel. The subscriber unit stores all 
archive files in a subdirectory corresponding to the ses- 

20 sion ID of the webcast. Preferably, when a main file is 
received that is newer than the current main file in that 
directory, all other files in that directory will be removed 
and any links in the proxy server's cache map file for this 
webcast will be replaced with the URIs in the new main 

25 file. 

[0099] In accordance with the present i invention , the 
subscriber unit preferably maps uniform resource loca- 
tors (URIs) to archive files. The map allows the sub- 
scriber unit to locate the archive file containing a URI 

30 that the user desires to view. When the subscriber unit 
receives the main file, the subscriber unit removes all 
files and cache map file links to the associated session 
prior to the receipt of the new main file. When the user 
requests a webpage, the subscriber unit extracts and 

35 decompresses the appropriate archive file data to a 
socket. This extraction is done in real time rather than 
extracting the entire archive file to disk. The subscriber 
unit also preferably has the capability to save partially 
downloaded files and acquire missing portions of the 

40 files on the next broadcast of the files as with all BFDP 
deliveries. 

[0100] In accordance with the present i invention , the 
headend unit is capable of manipulating the archived 
files using functions that archive files, determine the 

45 number of files in an archive file, return the name of a 
particular entry in an archive file, remove entries from 
an archive file, and merge a number of archive files into 
one archive file. The function that puts entries into an 
archi ve f il e i ncludes a f i eld denoti ng the f il e or f iles to be 

so archived. Preferably, wildcard indicators may be used to 
specify a number of filenames for entry into the archive 
file. The archive function also preferably allows for a 
speciication of a location to which the archive file 
should be written (e.g., a path name). In a preferred 

55 embodi ment the archive function allows for specification 
of compression or no compression for the archived file. 
The archive function parses the specified files, reads 
the hypertext transport protocol (HTTP) header, and 
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archives the specified files to an output file using the 
URI found in the HTTP header. 
[0101 ] A function that counts the number of files in 
an archive is also preferably implemented at the head- 
end unit. This function allows for a specification of an 
archive filename and returns the number of files stored 
in the archive file. Another desirable function is that of a 
function that returns the name of a file located in an 
archive file. This function allows for specification of an 
archi ve f il ename, the i ndex or location of the ( ile in ques- 
tion, the name of a buffer that will be filled with the name 
ol the file in question, and the size of the specified 
buffer. Based on the inputs specified this function pref- 
erably returns the name of the file located in the speci- 
fied index position in the specified archive file, the size 
ol the file, and the length of the character string returned 
in the buffer size. 

[0102] A function that erases portions of an archive 
file is also desirable. This erasing function allows for the 
specification of the archive file in question, the array 
index or indices to be erased from the archive file, and 
the number of elements specified in the index or indices 
to be erased. Preferably, a function is included that 
allows for the merging of two archive files. This merging 
function allows for the specification of two archive file 
names. One of the archive filenames is the file that is to 
be merged into the archive file bearing the other speci- 
fied filename. 

VIII. Conclusion 

[0103] Of course, it should be understood that a 
range of changes and modifications can be made to the 
preferred embodiment described above. It is therefore 
intended that the foregoing detailed description be 
regarded as illustrative rather than limiting and thai it be 
understood that it is the following claims, including all 
equivalents, which are intended to define the scope of 
this invention. 

Claims 

1 . A computer based graphical user interface lor facil- 
itating the selection and display ol transmitted 
audio, video, and data, comprising: 

an active video segment adapted to display a 
currently tuned program; 
a category segment listing various categories 
of programs or services available for viewing; 
a video/picture segment having a plurality of 
video/picture areas associated with the cate- 
gory segment, wherein selection of a one 
video/picture area invokes the interface to com- 
mand a receiver to tune to a particular program 
or service associated with the one video/pic- 
ture area and to display the particular program 
in the active video segment; and 



a graphic/link segment, wherein selection of a 
graphic/link invokes a (unction associated with 
the graphic/link. 

s 2. The interface of claim 1, wherein the graphic/link 
segment includes a web graphic/link indicating that 
there is a web page related to at least one 
video/picture area from the plurality of video/picture 
areas. 

w 

3. The interface of claim 1, wherein the graphic/link 
segment includes grid-guide links that invoke the 
interface to display a program grid-guide. 

is A. The interface of claim 1, wherein the graphic/link 
segment includes video-clip links that invoke the 
display of video clips in the video/picture segment. 

5. The interface of claim 1, wherein the graphic/link 
20 segment includes software links that invoke the 

download of software to the receiver. 

6. The interface of claim 1, wherein the graphic/link 
segment includes software links that invoke the dis- 

25 play of a data catalog that provides a schedule of 
when particular computer programs/web pages will 
be broadcast and available for download to the 
receiver. 

30 7. The interface of claim 1, wherein the graphic/link 
segment includes links that invoke the purchase 
and display of a pay-per-view program. 

8. The interface of claim 1 , further comprising a page 
35 segment, whereby a user may select from one or 

more pages associated with a particular category. 

9. The interface of claim 1 , further comprising a time 
line associated with one or more of the video/pic- 

40 ture areas. 

10. The interface of claim 1, wherein the categories 
within the category segment listing include at least 
one from the group of categories consisting of mov- 

45 ies, sports, news, kids & family, shopping, music, 
educational, entertainment, and favorites. 

11. The interface of claim 1, wherein the video/picture 
segment has six 3:4 aspect ratio video picture 

so areas. 

12. The interface of claim 1, further including one or 
more auxiliary display areas. 

55 13. A method for facilitating the selection and display of 
transmitted audio, video, and data, comprising: 

displaying in a category segment a listing of the 
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various categories of programs available for 
viewing; 

displaying in an active video segment a 
video/service channel to which a receiver is 
currently tuned; 5 
displaying a graphic/link segment containing a 
least one graphic/link that invokes a feature or 
service associated with the graphic/link; 
displaying a video/picture segment having a 
plurality of video/picture areas associated with ia 
the category segment; 

receiving an input from a user, the input being 
a selection of a one video/picture area selected 
from the plurality of video/picture areas; 
commanding a receiver to tune to a particular is 
program or service associated with the one 
video/picture area; and 

displaying the particular broadcast program in 
the active video segment. 

20 

14. The interface of claim 13, wherein the graphic/link 
segment includes a web graphic/link indicating that 
there is a web page related to at least a one from 
the plurality of video/picture areas. 

25 

15. The interface of claim 13, wherein the graphic/link 
segment includes grid-guide links that invoke the 
interface to display a program grid-guide. 



within the category segment listing include at least 
one from the group of categories consisting of mov- 
ies, sports, news, kids & family, shopping, music, 
educational, entertainment, and favorites. 

23. The interface of claim 1 3, wherein the video/picture 
segment has six 3:4 aspect ratio video picture 
areas. 

24. The interface of claim 13, further including the step 
of displaying one or more auxiliary display areas. 



16. The interface of claim 13, wherein the graphic/link 30 
segment includes video-clip links that invoke the 
display of video clips in the video/picture segment. 



17. The interface of claim 13, wherein the graphic/link 
segment includes software links that invoke the 3s 
download of related software to the receiver. 



18. The interface of claim 13, wherein the graphic/link 
segment includes software links that invoke the dis- 
play of a data catalog that provides a schedule of 4c 
when particular computer programs/web pages will 
be broadcast and available for download to the 
receiver. 



19. The interface of claim 13, wherein the graphic/link 45 
segment includes links that invoke the purchase 
and display of a pay-per-view program. 



20. The display of claim 13, further including the step of 
displaying a page segment, whereby a user may so 
select from one or more pages associated with a 
particular category. 



21. The display of claim 13, further including the step of 
displaying a time line associated with one or more ss 
of the video/picture areas. 



22. The interlace ol claim 13, wherein the categories 
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IP Packet Header (Version 4) 632 
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Example Ticker SDP+ Record 
v=0 

o=DTV0001 17DSSP4 
s=Aiuiouncement Dump 
c=DSSIP4 233.17.43.671 
t-00 

m=data 3287 UDP STREAM 
a=key:l 

a=run;consoleticker 
a=keywds:tsetup 

FIG.16A 



Example File Download SDP+ Record 
v=0 

o=DTV000S17DSSIP4 

s=Data Catalog 

c=DSSIP4 233.17.43.3/1 

t=3079382400 3155745600 

r=10m 10m 0 

m=data 3335 UDP BFDP 

a=key:8 

a=fsr980000 

a=mandatory 

a=run:cataloginsta]l.exe 

FIG.16B 
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Example Webcast SDP+ Record 
v=0 

o=DTV 900 17DSSP4 
s=CNN 

i=Rtsearch financial markets worldwide, get stack quotes, and calculate your 
mortgage payments - all on-line. Read the "hot stories" of the week in the financial 
world. Complete listing of CNN's Financial Network television broadcasts. 
u~http://www.cnn. com/index.htm 
c=DSSIP4 233. 17.43.7/1 
t=0 0 

m=data 3334 TJDP WEBCAST 

a=cat:News 

a=key:900 

a=fsz: 16000000 

a=display3ype=l, priority=8 

a=img:cnn.gif 

FIG.16C 

Example data enriched video SDP+ record 
v=0' 

o=DTV0201 17DSSIP4 
s=CNBC 

c=DSSIP4 233.26.24.24/1 
t=00 

m=data 6500 TJDP INTERCAST 

a=key:201 

a=channel:775 

FIG.16D 
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Description 

[0001] The present invention relates to a method to 
transfer data packets over a public data packet nelwork 
and a mobile data packet network to a plurality of mobile 
slations as defined in the non-characteristic part of claim 
1 , a gateway node for interfacing between the public da- 
ta packet network and the mobile data packet nelwork 
as defined in 1he non-characteristic part of claim 2, a 
service node for serving mobile stations in the mobile 
data packet network as defined in the non-characteristic 
part of claim 6, and a routing node for routing dala pack- 
ets in between gateway nodes and service nodes of the 
mobile data packet network as defined in the non-char- 
acteristic part of claim 9. 

[0002] Such a method for transferring data packets 
through a mobile data packet network, as well as a gate- 
way node, service node and routing node of the mobile 
data packet network are already known in the art, e.g. 
from the standard specification "Digital Cellular Teie- 
communications System (Phase 2+); Genera! Packet 
Radio Service (GPRS); Service Description; Stage 2", 
published by ETSI (European Telecommunications 
Standards Institute) under the reference TS/SMG- 
030360Q. This standard specification is also named 
"GSM 03,60 Version 8,0.0" but will be referred to by 
"GPRS Specification" in the remainder of this patent ap- 
plication. The GPRS Specification describes a data 
packel service lor a mobile communication network that 
makes use of the GSM (Global Syslem for Mobile Com- 
munications) air interface lor the communication be- 
tween base stations and mobile stations. For Ihe com- 
munication up to the base stations, the GPRS Specifi- 
cation introduces two new network nodes: a Gateway 
GPRS Support Node (GGSN) provides inter-working 
between an external or public packet switching nelwork 
and the mobile or private packet switching network, 
whereas a Serving GPRS Support Node (SGSN) keeps 
track of the individual mobile stations within a certain 
service area, and performs security functions, access 
control and mobility lunctions, e.g. change of SGSN by 
a mobile station. The architecture ol a GPRS (General 
Packet Radio Service) system built up of Gateway 
GPRS Support Nodes, Serving GPRS Support Nodes, 
Base Stations and Mobile Slations is illustrated by Fig- 
ure 2 and Figure 3 respectively on page 18 and 19 of 
the above cited GPRS Specification. Figure 4 on page 
21 gives an overview of 1he protocol stack used for 
transferring data packels through the GPRS system. To 
route data packets received from an external dala pack- 
et network like the internet to a mobile station in the 
known GPRS system, a so called point-to-point tunnel 
is set up from the Gateway GPRS Support Node 
(GGSN) that receives the data packets from the external 
data packet networktolhe Serving GPRS Support Node 
(SGSN) in whose service area the mobile station is re- 
siding. This means lhat the external data packets are 
encapsulated in internal data packets in the Gateway 



GPRS Support Node ; that these internal data packets 
are routed to the Serving GPRS Support Node accord- 
ance with an internal rouling protocol, and that the ex- 
ternal data packets are de-capsulated from the internal 

5 data packets in the Serving GPRS Support Node to be 
forwarded to Ihe Base Station that will send the data 
packets 1o the mobile station over the air interface. 
[0003] If in the known GPRS system Ihe same data 
packets have 1o be transferred to more than one mobile 

to station residing in the same service area, for instance 
because these mobile stalions are members of the 
same multicast group in the external network, Ihese da- 
ta packets will independently be forwarded from the 
Gateway GPRS Support Node (GGSN) to the different 

1$ mobile stations via separate point-to-point lunnels. In 
such situations, network resources are inefficiently used 
in the known mobile dala packet network because du- 
plicated data packets are transferred over the common 
part of the routes to the different mobile terminals. 

20 [0004] An object of the present invention is to provide 
a method for transferring dala packets through a mobile 
data packet network, as well as a gateway node, a serv- 
ice node and a routing node similar to the above known 
ones, but which use network resources, i.e. bandwidth 
capacity, more efficiently in case Ihe same data packets 
have 1o be routed to a plurality of mobile terminals. 
[0005] According to the invention, this object is 
achieved by the method to transfer data packets over a 
public data packet network and a mobile data packet 

so nelwork to a plurality of mobile stations as defined in 
claim 1, the gateway node for interfacing between the 
public data packel network and the mobile data packet 
network as defined in claim 2, the service node for serv- 
ing mobile stations in the mobile data packet network as 

35 defined in claim 6 : and the rouling node for routing data 
packets in between gateway nodes and service nodes 
of the mobile dala packet network as defined in claim 9. 
[0006] Indeed, by multi-casting the internal data pack- 
ets (named private dala packets in the remainder of this 

40 patent application because they are routed within the 
mobile dala packet network that is usually owned by a 
private operator) that tunnel external data packets 
(named public data packets in the remainder of this pat- 
ent application because they are routed through a public 

45 data packet network such as the inlernet) thai belong to 
an exlernal multi-cast connection, it is avoided thai the 
same public data packets are duplicated and encapsu- 
lated in differenl private data packets that are trans- 
ferred over at least partially common routes in the mo- 

50 bile data packet network. Multi-casting internal data 
packets is realised via internal multi-cast addresses as- 
sociated with external multi-cast groups where a mobile 
station can subscribe to. When a gateway node receives 
public data packets for a multi-cast connection, it will 

55 send these data packets on the private multi-cast tree 
which contains service nodes lhat contain members of 
the external multi-cast group in their service area. The 
service nodes further send the data packets to the mo- 
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bile stations that are member of the multi-cast group via 
point-to-point connections. In this way, the network re- 
sources for transfer of data between the gateway nodes 
and the service nodes are used more efficiently and the 
capacity of the mobile data packet network is enlarged 
significantly in particular if the share of multi-cast traffic 
in the aggregate data traffic is significant. 
[0007] It is 1o be noticed that the term 'comprising': 
used in the claims, should not be interpreted as being 
limitative to the means listed thereafter. Thus, the scope 
of the expression 'a device comprising means A and B 1 
should not be limited to devices consisting only of com- 
ponents A and B It means that whh resped to 1he 
present invention, the only relevant components of the 
device are A and B. 

[0008] Similarly, it is to be noticed that the term 'cou- 
pled 1 , also used in the claims, should not be interpreted 
as being limitative to direct connections only Thus, the 
scope of the expression 'a device A coupled to a device 
B' should not be limited to devices or systems wherein 
an output of device A is directly connected to an input 
of device B. It means that there exists a path belween 
an output of A and an input of B which may be a path 
including other devices or means. 
[0009] An additional feature ol the gateway node ac- 
cording to the present invention is defined by claim 3. 
[0010] This, a mobile station can become member of 
a public multi-cast group by transmitting a public join 
message towards a galeway node. The gateway node 
can interpret this public join message and inform the 
service node in whose service area the mobile station 
is residing, that the mobile station becomes member of 
the public mulli-cast group via a private join message. 
The private join message is addressed to the service 
node and contains the public join message received by 
the gateway node. 11 is necessary to first transfer the 
public join message to the gateway node and to feed 
back the public join message encapsulated in a private 
message to the service node because the service node 
cannot interpret the public join message transmitted by 
the mobile station towards the gateway node. 
[0011] An alternative way of joining the public multi- 
cast group requires 1hat 1he mobile station sends a 
GPRS specific join message that can be interpreted by 
both the service node and the gateway node. This alter- 
native does not require feedback ol join messages from 
the gateway node to the service node but involves mod- 
ification ol the GPRS standard specification because 
the format ol such a GPRS specific join message has 
to be standardised. 

[001 2] An othe r f ea1 u re of th e galeway nodeaccording 
to 1he present invention is defined in claim 4. 
[0013] In this way, by assigning to the private multi- 
cast group that is associated with a public multi-cast 
group a private multi-cast address that is equal to the 
public multi-cast address, complexity of the address as- 
sociation means in the gateway node is minimised. No 
table linking the private multi-cast addresses with the 



public multi-cast addresses has to be maintained in 
gateway nodes and service nodes. 
[0014] Compared to claim 4, an alternative implemen- 
tation of the gateway node according to the present in- 

5 vention is defined by claim 5. 

[0015] In this way, the address association means in 
the gateway node needs to keeptrackof atable wherein 
public multi-cast addresses and associated private mul- 
ti-cast addresses are memorised which makes the ad- 
io dress association means more complex but creates a 
grealer flexibility in assignment and use of private multi- 
cast addresses. 

[0016] An additional feature ol 1he service node ac- 
cording to the present invention is defined in claim 7. 

'5 [0017] Thus, the service node is able to maintain a list 
of mobile stations which are member of a public multi- 
cast group. The service node updates the table wherein 
public multi-cast addresses, private multi-cast address- 
es and mobile stations are linked upon receipt of join/ 

20 leave messages sent to it by a gateway node. 

[0018] As an alternative to claim 7, claim 8 specific 
that the table wherein public multi-cast addresses, pri- 
vate multi-casl addresses and mobile slations are linked 
may be updated upon receipt of GPRS specific join/ 

6 leave messages from mobile slations that want to join/ 
leave a public multi-cast group. Such a GPRS specific 
join/leave message can be interpreted by the service 
node if its format is standardised. 

[0019] The above mentioned and other objects and 
so features ol the invention will become more apparent and 
the invention itself will be best understood by referring 
to the following description of an embodiment taken in 
conjunction with the accompanying drawings wherein: 

35 Fig. 1 represents an architectural scheme of a sys- 
tem including gateway nodes GGSN1 and GGSN2 
according to 1he present invention, service nodes 
SGSN1 , SGSN2, SGSN3, SGSN4and SGSN5 ac- 
cording to the present invention, and routing nodes 

40 DPR1 , DPR2, DPR3, DPR4, DPR5 and DPRS ac- 
cording 1o the present invention; 
Fig. 2 illustrates the structure of aprivate dala pack- 
et PR-DP multi-casted according to the present in- 
vention; 

45 Fig. 3 represents a functional block scheme of an 
embodiment ol the gateway node GGSN1 accord- 
ing to the present invention; and 
Fig. 4 represents a functional block scheme of an 
embodiment of Ihe service node SGSN3 according 

50 to the present invention. 

[0020] Fig. 1 shows the internet INTERNET and a 
General Packel Radio Service system GPRS-SYSTEM. 
The internet INTERNET contains a plurality ol IP (Inter- 
55 net Protocol) routers IPR1, IPR2, IPR3 and IPR4 inter- 
connected via links and one terminal TE of the internet 
INTERNET is also drawn. The General Packet Radio 
Service system GPRS -SYSTEM contains two Gateway 
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GPRS Supporting nodes GGSN1 and GGSN2, a 
number of data packet routers DPR1, DPR2, DPR3. 
DPR4, DPR5 and DPR6, five Service GPRS Supporting 
nodes SGSN1 , SGSN2, SGSN3, SGSN4 and SGSN5 : 
and five base stations BS1, BS2, BS3, BS4 and BS5. 
Also six mobile stations or lerminals of the GPRS-SYS- 
TEM are drawn in Fig. 1: MS1, MS2 : MS3, MS4, MS5 
and MS6. 

[0021] In the internet INTERNET, the first IP router 
IPR1 is connected to bolh the second IP router IPR2 
and to the third IP router IPR3. The second IP router 
IPR2 is connected to the fourth IP router IPR4, the third 
IP router IPR3 is connected respectively to the first gate- 
way node GGSN1 and lo Ihe fourth IP router IPR4, and 
the just mentioned fourth IP router IPR4 is connected to 
the second gateway node GGSN2. The terminal TE is 
interconnected with Ihe second IP router IPR2. In the 
GPRS-SYSTEM, the first gateway node GGSN 1 is con- 
nected to both the first data packet router DPR1 and the 
second data packet router DPR2. The first data packet 
router DPR1 additionally is interconnected with the third 
data packet router DPR3 and the first service node 
SGSN1 , whereas Ihe second data packet router DPR2 
is only interconnected with the third service node 
SGSN3. The third data packet router DPR3 is connect- 
ed to the first service node SGSN1, the second service 
node SGSN2 and the third service node SGSN3. These 
first, second and third service nodes SGSN1, SGSN2 
and SGSN3 are respectively connected to the first, sec- 
ond and third base stations BS1 , BS2 and BS3. The sec- 
ond gateway node GGSN2 is connected to the fourth 
data packet router DPR4. This fourth data packet router 
DPR4 further is connected to the fifth data packet router 
DPR5 and to the sixth data packet router DPR6. The 
filth data packet router DPR5 and the fifth service node 
SGSN5 are interconnected, and also the sixlh data 
packel router DPR6 and thefourth service node SGSN4 
are interconnected. The just mentioned fourth service 
node SGSN4 is connected to the fourth base station 
BS4and the earlier mentioned filth service node SGSN5 
is connected to the fifth base station BS5. The first mo- 
bile station MS1 is located within ihe service area of ihe 
first service node SGSN1, the second mobile station 
MS2 as well as the 1hird mobile station MS3 are located 
wflhin the sen/ice area of the third service node SGSN3. 
Mobile stations MS4, MS5 and MS6 are all located in 
the service area of the fifth service node SGSN5. 
[0022] In the internet INTERNET data are communi- 
cated in accordance with the internet protocol (IP). Data 
in other words are encapsulated in IP packels PU-DP. 
Such an IP packet PU-DP is shown in Fig. 2 and con- 
tains an overhead section or I P header PU-H and a pay- 
load section wherein user data can be embedded. One 
field of the IP header PU-H carries the address ol the 
destination of the IP data packet PU-DP In case the IP 
data packet PU-DP isdestined to all members of amulti- 
cast group : the sender of the I P data packet PU-DP will 
embed an internet multi-cast address PU-MCA in the 



destination address field of that IP data packet PU-DP. 
The internet terminal TE in Fig. 1 for example is sup- 
posed to have sent an IP data packel PU-DP to such a 
multi-cast group. The IP routers IPR1 , IPR2, IPR3 and 

5 IPR4 have the task lo roule IP data packets from Iheir 
origin to their destination(s). The IP routers IPR1, IPR2, 
IPR3 and IPR4 thereto look at the contenls of the des- 
tination address field of the IP data packets they receive 
and can route the IP data packets either by consulting 

10 routing tables or via explicit routing techniques. In case 
an IP router, IPR1 , IPR2, IPR3 or IPR4 receives an IP 
data packet PU-DP whose destination address field 
contains an inlernet multi-cast address PU-MCA, the I P 
router will multi-cast the data packet PU-DP: the data 

'5 packet PU-DP is Ihen forwarded to the IP roulers that 
joined the multi-cast tree whereover such IP data pack- 
ets PU-DP are routed towards all members of the multi- 
cast group. 

[0023] In the GPRS-SYSTEM data packets are rout- 
20 ed towards mobile stations in accordance with the 
GPRS standard specification, whereto reference is 
made in the introductory part of this patent application. 
The galeway nodes GGSN1 and GGSN2 provide inter- 
working with Ihe internet INTERNET and encapsulate 

6 an IP data packet PU-DP received from the internet IN- 
TERNET in a private data packet PR-DP that can be 
routed through the GPRS-SYSTEM towards the desti- 
nation mobile stations This operation is known as tun- 
neling. Such a private data packet PR-DP wherein the 

so |p data packet PU-DP is encapsulated, is shown in Fig. 
2. This private data packet PR-DP also contains an 
overhead section PR-H and a payload section wherein 
the IP data packet PU-DP is embedded. In accordance 
with the GPRS standard specification, the private data 

35 packet PR-DP is a private IP (Internet Protocol) packet 
and consequently the overhead section PR-H thereof is 
an IP (Internet Protocol) header wherein also one field 
is reserved for the destination address of the private da- 
ta packet PR-DP. As will be explained further, the gate- 

40 way node GGSN1 that encapsulates the IP data packet 
PU-DP in the private data packet PR-DP fills the desti- 
nation address field of the privale data packet header 
PR-H with a private multi-cast address PR-MCA when 
the destination address field of the IP data packet PU- 

45 DP conlains an internet mulli-cast address PU-MCA. 
[0024] The data packet routers DPR1 , DPR2, DPR3, 
DPR4, DPR5 and DPRB include the functionality to 
route a private data packet PR-DP to its destination or 
destinations and, similarly to Ihe IP routers IPR1, IPR2, 

50 IPR3 and IPR4 in the inlernet INTERNET, thereto look 
at the contents of the destination address field of the 
private data packets PR-DP and consult routing tables 
or perform explicit routing techniques. The service 
nodes SGSN1, SGSN2, SGSN3, SGSN4 and SGSN5 

55 keep track of the locations ol the mobile stations and 
perform mobility security functions and access control 
compliant with the GPRS standard specification. Via the 
base stations BS1 , BS2, BS3, BS4 and BS5, Ihe service 
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nodes SGSN1, SGSN2, SGSN3, SGSN4 and SGSN5 
are able to set up radio connections to the mobile sta- 
tions MS1 , MS2, MS3, MS4, MS5 and MS6 so that the 
data packets can be delivered to 1he mobile stations 
MS1, MS2, MS3, MS4, MS5 and MS6. 
[0025] In the following paragraphs, it will be supposed 
that the internet terminal TE is the origin of internet data 
packels PU-DP destined to the members of a multi-cast 
group with internet multi-cast address PU-MCA. The 
mobile stations MS1 , MS2, MS3, MS4 and MS6 want to 
receive such data packets and thereto request 1o be- 
come member of this internet multi-cast group. The reg- 
istration of these mobile stations MS1 : MS2, MS3 : MS4 
and MS6 as members of the multi-cast group, as well 
as the way wherein the internet data packets PU-DP 
destined to 1he members of this multi-cast group are 
routed towards the mobile stations MS1 , MS2, MS3, 
MS4 and MS6 in accordance with the principles of the 
present invention will be explained in the next para- 
graphs. Reference will be made to Fig. 3 and Fig. 4 in 
these paragraphs to address the required functionality 
respectively in Ihe gateway nodes GGSN1 and GGSN2 
and the service nodes SGSN1, SGSN2, SGSN3 ; 
SGSN4 and SGSN5 to be able to fulfil the principles of 
the present invention. 

[0026] Gateway node GGSN1 of Fig. 1 is drawn in 
more detail in Fig. 3 and includes an internet multi-cast 
address recognition device PU-RECOGNITION, a mul- 
ti-cast address association device PU-PR-ASSOCIA- 
TION, a private data packel generator PR-GENERA- 
TION, a private data packel transmitter PR-TX, a multi- 
cast address lable PU-PR-TABLE, a routing table 
ROUTING-TABLE, a public join/leave message receiv- 
er PU-JN/LV RX, and a private join/leave message gen- 
erator PR-JN/LV GENERATOR. 
[0027] The internet mulli-cast address recognition de- 
vice PU-RECOGNITION, the multi-cast address asso- 
ciation device PU-PR-ASSOCIATION, the private data 
packel generator PR-GENERATION, and the private 
data packet transmitter PR-TX are cascade coupled be- 
tween a port of the gateway node GGSN1 whereto the 
third IP router IPR3 is connected in Fig. 1 and a port of 
the gateway node GGSN1 whereto 1he data packet rout- 
ers DPR1 and DPR2 of Ihe GPRS-SYSTEM in Fig. 1 
are coupled. The multi-cast address table PU-PR-TA- 
BLE interfaces with the multi-cast address association 
device PU-PR-ASSOCIATON, and the routing table 
ROUTI NG-TABLE interfaces with the privale data pack- 
et transmitter PR-TX. The public join/leave message re- 
ceiver PU-JN/LV RX is connected to the port of gateway 
node GGSN1 whereto data packet roulers DPR1 and 
DPR2 are coupled. The public join/leave message re- 
ceiver PU-JN/LV RX lurther is coupled to Ihe private da- 
ta packet transmitter PR-TX via the private join/leave 
message generator PR-JN/LV GENERATOR, and also 
interfaces with the routing table ROUTING-TABLE. 
[0028] The service node SGSN3 of Fig. 1 is drawn in 
more detail in Fig. 4 and includes a private multi-cast 



address recognition device PR-RECOGNITION, a pri- 
vate data packet copier and transmitter COPY/SEND, a 
multi-cast group registration device MS-REGISTRA- 
TION, and a private join/leave message receiver PR- 

5 JN/LV RX. 

[0029] The private multi-cast address recognition de- 
vice PR-RECOGNITION and the private data packet 
copier and transmitter COPY/SEND are cascade cou- 
pled belween a port of the service node SGSN3 that is 

10 coupled to the data packet routers DPR2 and DPR3 in 
Fig. 1 , and a port of the service node SGSN3 whereto 
the base stalion BS3 is coupled. To the port coupled to 
data packel routers DPR2 and DPR3 also the private 
join/leave message receiver PR-JN/LV RX is connected 

1$ and this private join/leave message receiver PR-JN/LV 
RX has an oulput terminal coupled to an inpul terminal 
the multi-cast group registration device MS-REGIS- 
TRATION. The multi-cast group registration device MS- 
REGISTRATION interfaces with the private data packet 

zo copier and transmitter COPY/SEND. 

[0030] If the second mobile station MS2 wants to be- 
come member of the multi-cast group with inlernet multi- 
cast address PU-MCA, il will send a public join message 
to the service node SGSN3 in whose service area the 
mobile station MS2 is residing. The service node 
SGSN3 cannot interpret this public join message and 
transparently translers the join message via the data 
packet routers to gateway node GGSN1 In the gateway 
node GGSN1, the public join/leave message receiver 

so PU-JN/LV RX receives the public join message and in- 
terprets this message. The privale multi-cast tree in 
GPRS-SYSTEM is updated so lhat the internet data 
packets PU-DP addressed to the internet multi-cast ad- 
dress PU-MCA will be routed to the mobile station MS2. 

35 in addition, 1he public join message is encapsulated in 
a private join message by the private join/leave mes- 
sage generator PR-JN/LV GENERATOR and this pri- 
vate join message is sent to the service node SGSN3 
in whose service area mobile station MS2 is residing. In 

40 this way, Ihe service node SGSN3 is made aware that 
the mobile slation MS2 becomes member of the multi- 
cast group with the internel multi-cast address PU-MCA 
and private multi-cast address PR-MCA. Indeed, this 
multi-cast group is addressed within the GPRS-SYS- 

45 TEM with a private multi-cast address PR-MCA that is 
linked to the public multi-cast address PU-MCA via a 
table PU-PR-TABLE in the gateway node GGSN1 and 
via the multi-cast group registration device MS-REGIS- 
TRATION in the service node SGSN3. The just men- 

50 tioned multi-cast group registration device MS-REGIS- 
TRATION upon instruction of the private join/leave mes- 
sage receiver PR-JN/LV RX memorises that mobile sta- 
tion MS2 becomes member of the multi-cast group with 
public multi-cast address PU-MCA and private multi- 

55 cas1 address PR-MCA. It is the task ol the gateway node 
GGSN1 lo mention to the IP router I PR3 that it wants to 
join the internet multi-cast group with internet multi-cast 
address PU-MCA. Similarly to mobile station MS2, mo- 
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bile station MS3 will join the public multi-cast group with 
internet multi-cast address PU-MCA. A public join mes- 
sage is transmitted towards gateway node GGSN1 and 
returned as a private join message to Ihe service node 
SGSN3 in whose area the mobile station MS3 is located. 
In the multi-cast group registration device MS-REGIS- 
TRATION it is memorised that mobile slation MS3 also 
wants to receive the private data packels destined tolhe 
multi-cast group with public multi-cast address PU-MCA 
and private multi-cas1 address PR-MCA. Also mobile 
slations MS1 : MS4 and MS6 become members of the 
multi-cast group which is addressed by the internet mul- 
ti-cast address PU-MCA in the INTERNET and which is 
addressed by the private multi-cast address PR-MCA in 
the GPRS-SYSTEM. Mobile station MS1 for example is 
registered as member of this multi-cast group in the 
service node SGSN1, In a similar way service node 
SGSN5 registers that the mobile stations MS4 and MSB 
have joined this multi-casl group. 
[0031] Summarising, a registration mechanism is pro- 
vided in the GPRS-SYSTEM whereby the service nodes 
SGSN 1 , SGSN2, SGSN3 : SGSN4and SGSN5 register 
which mobile terminals MSI , MS2 ; MS3, MS4 and MSB 
joined a public mulH-cast group via a join message that 
is sent to a gateway node and returned thereby as a 
private join message. In case a mobile station moves to 
another service area, the registered information mus1 be 
updated. This update may form part ol the inter SGSN 
routing area update procedure in a cellular mobile sys- 
tem. In case a mobile station wants to be deleled as 
member of a public multi-cast group, it will send a leave 
message which is Ireated in a similar way as the join 
messages. The service node thereupon de-registers the 
mobile slalion as member of the multi-cast group. 
[0032] If an internet server or a terminal TE transmits 
internet data packets PU-DP addressed to members of 
the internet multi-cast group with internet mulli-cast ad- 
dress PU-MCA, these packets will be routed to the gate- 
way nodes GGSN1 and GGSN2 because these gate- 
way nodes joined the multi-casttree associated with that 
internet multi cast group as explained above. The inter- 
net mulli-cast address recognition device PU-RECOG- 
NITION in gateway node GGSN1 detects that the re- 
ceived internet data packet PU-DP is addressed to the 
internet multi-cast group by recognising internet multi- 
cast address PU-MCA in the destination address field 
of the inlernet data packet PU-DP. The internet multi- 
cast recognition device PU-RECOGNITION instructs 
the multi-cast address association device PU-PR-AS- 
SOCIATION to retrieve from the multi-casl address ta- 
ble PU-PR-TABLE the private multi-cast address PR- 
MCA thai is associated with 1he internet multi-cast ad- 
dress PU-MCA. This private multi-cast address PR- 
MCA in an alternative embodiment of the invenlion with- 
out multi-cast address table PU-PR-TABLE may be 
equal to the public multi-cast address PU-MCA. The in- 
ternet data packet PU-DP is encapsulated in a private 
data packet PR- DP by the p rival e data packet generator 



PR-GENERATION and is forwarded by the privale data 
packet transmitter PR-TX over the private multi-cast 
tree addressed via private multi-cast address PR-MCA. 
The private data packet transmitter PR-TX thereto con- 
s suits the routing table ROUTING-TABLE. The internet 
data packet PU-DP, encapsulated in the private data 
packet PR-DP consequently is multi-casled once to the 
service node SGSN3 and not transferred two times to 
service node SGSN3 because two mobile stations MS2 
10 and MS3 in its service area want to receive this data 
packet PU-DP. In the service node SGSN3, the private 
multi-cast address recognition device PR-RECOGNI- 
TION recognises the private multi-cast address PR- 
MCA in the header PR-H ol the privale data packet PR- 
'S DP and thereupon instructs the data packet copier and 
transmitter COPY/SEND to send copies of the data 
packet PU-DP to all mobile stations, MS2 and MS3, that 
are member of the public multi-cast group addressed 
via the public mulli-cast address PU-MCA. The private 
zo data packel copier and transmitter COPY/SEN D thereto 
consults the memory of the multi-cast group registration 
device MS-REGISTRATION. In a similar way as de- 
scribed for mobile stalions MS2 and MS3, the public da- 
ta packet PU-DP will be routed to the mobile station MS1 
& and will be routed to the mobile stalions MS4 and MSB. 
To transfer the data packet PU-DP to mobile stations 
MS4 and MS6, the data packet again will be multi-cast- 
ed only once to service node SGSN5, which will dupli- 
cate the data packet PU-DP and send a copy to each 
so one of the mobile stations MS4 and MSB. 

[0033] Summarising, the private data packels PR-DP 
wherein public data packets PU-DP destined to an in- 
ternet multi-cast group are encapsulated, are multi-cast- 
ed in ihe GPRS-SYSTEM up to the level of the service 
35 nodes. This is made possible by associaling private mul- 
ti-cast groups wilh the internet multi-cast groups and by 
maintaining in the service nodes which mobile stations 
are member of the different public multi-cast groups. In 
this way, the required bandwidth for transfer of multi- 
40 casl traffic belween the gateway nodes and the service 
nodes of the GPRS-SYSTEM is reduced significantly. 
[0034] Although implementation of the invention has 
been described above for transfer of internet data pack- 
ets over the internet and over a GPRS system interfac- 
es ing with the internet, it is clear that the same principles 
can be applied to transfer for example IP or X.25 data 
packets over respectively an IP or X.25 network and a 
UMTS (Universal Mobile Telecommunications System) 
system, interfacing with the IP or X.25 network. In fact 
50 the invention can be applied in any system wherein pri- 
vate mobile data packets tunnel public data packets re- 
ceived from a public or external data packet network to- 
wards mobile stations, irrespective of the particular pro- 
tocol that is used in the public data packet network and 
55 the mobile network. 

[0035] It is also remarked that introduction ol the 
present invention in a GPRS system is not complex be- 
cause a GPRS system already uses the Internet Proto- 
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col to tunnel public data packets from Ihe gateway 
nodes to the service nodes. Introduction of privale multi- 
cast IP addresses l similar to the public multi-cast group 
IP addresses that are used in the internet makes the 
invention feasible. No adaptation of the protocol is re- s 
quired in the GPRS system to enable introduction of the 
present invention. 

[0036] Furthermore il is noticed that the private multi- 
cast address and public multi-cast address associated 
whh each other can be equal. The association of a pn- 10 
vate mulli-cast address with a public multi-cast address 
then becomes very simple because no tables are re- 
quired in 1he gateway nodes and service nodes. The 
flexibility in use of privale addresses is increased if the 
private multi-cast address associated with a public mul- is 
ti-casl address is not equal thereto. The link belween 
private and public multi-cast addresses then however 
has to be memorised in a centralised or distributed da- 
tabase. 

[0037] While 1he principles of the invention have been 20 
described above in connection with specific apparatus, 3. 
it is to be clearly understood that this description is made 
only by way of example and not as a limitation on the 
scope of the invention. 



Claims 

1. Method to transler public data packets (PU-DP) 
from an originating terminal (TE) to al least a plu- so 
rality ol mobile stations (MS1, MS2 : MS3 : MS4 : 
MSB) over a public data packet network (INTER- 
NET) and a mobile data packet network (GPRS- 
SYSTEM) whereby said public data packets (PU- 
DP) are multi-casted through said public data pack- 35 
et network (INTERNET) by means of a multi-cast 
address (PU-MCA) in an overhead section (PU-H) 

of said public data packets (PU-DP) 

CHARACTERISED IN THAT said public data 
packets (PU-DP) are further multi-casled through 40 4. 
at leasl pari of said mobile data packet nelwork 
(GPRS-SYSTEM) by means of a private multi-cast 
address (PR-MCA) in an overhead section (PR-H) 
of private data packets (PR-DP) that lunnel said 
public data packets (PU-DP) through at least said 45 
part of said mobile data packet network (GPRS- 
SYSTEM). 

2. Gateway node (GGSN1) lor interlacing between a 5. 
public data packet network (INTERNET) and a mo- so 
bile dala packet network (GPRS-SYSTEM), said 
gateway node (GGSN1) comprising: 

a. public mulli-cast address recognition 
means (PU-RECOGNITION) to recognise a public 
multi-cast address (PU-MCA) in an overhead sec- 55 
tion (PU-H) of public data packets (PU-DP) sent 
from an originating terminal (TE) to al least a plu- 
rality of mobile stations (MS1, MS2, MS3, MS4, 



MS6) over said public data packet network (INTER- 
NET) and said mobile data packet network (GPRS- 
SYSTEM), 

CHARACTERISED IN THAT said gateway 
node (GGSN 1 ) further comprises: 

b. address association means (PU-PR-ASSO- 
CIATION) to associate a private multi-cast ad- 
dress (PR-MCA) with said public multi-cast ad- 
dress (PU-MCA): and 

c. private data packet generation means (PR- 
GENERATION) to generale private data pack- 
ets (PR-DP) for tunnelling said public data 
packets (PU-DP) Ihrough at least part of said 
mobile data packet nelwork (GPRS-SYSTEM) 
towards said mobile slations (MS1, MS2, MS3, 
MS4, MS6), said private data packets (PR-DP) 
having said private multi-cast address (PR- 
MCA) in an overhead section thereof. 

Gateway node (GGSN 1 ) according to claim 2, 

CHARACTERISED IN THAT said gateway 
node (GGSN 1 ) further comprises. 

d. public join/leave message receiving means 
(PU-JN/LV RX), adapted to receive a join/leave 
message from a mobile station (MS2) indicat- 
ing that said mobile station (MS2) wants to join/ 
leave a public multi-cast group; and 

e. private join/leave message generating 
means (PR-JN/LV GENERATION), coupled to 
said public join/leave message receiving 
means (PU-JN/LV RX) and adapted to gener- 
ate a private data packet for tunnelling said join/ 
leave message from said gateway node 
(GGSN1) to a service node (SGSN3) of said 
mobile data packet network (GPRS-SYSTEM) 
serving said mobile station (MS2). 

Gateway node (GGSN1) according to claim 2 or 
claim 3, 

CHARACTERISED IN THAT said address as- 
sociation means (PU-PR-ASSOCIATION) is adapt- 
ed 1o associate with said public multi-cast address 
(PU-MCA) a private multi-cast address (PR-MCA) 
that is equal to said public multi-cast address (PU- 
MCA). 

Gateway node (GGSN1) according to claim 2 or 

claim 3, 

CHARACTERISED IN THAT said address as- 
sociation means (PU-PR-ASSOCIATION) is adapt- 
ed 1o associate with said public multi-cast address 
(PU-MCA) a private multi-cast address (PR-MCA) 
linked 1o said public multi-cast address (PU-MCA) 
via a table (PU-PR-TABLE) comprised in said gate- 
way node (GGSN 1 ). 
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6. Service node (SGSN3) for serving in a mobile data 
pocket network (GPRS-SYSTEM) dala packet 
communication to mobile stations (MS2, MS3) with- 
in a certain service area, 

CHARACTERISED IN THAT said service 5 
node (SGSN3) comprises: 

a. private multi-cast address recognition means 
(PR-RECOGNITION) to recognise a private 
multi-cast address (PR-MCA) in an overhead 10 
section (PR-H) of private data packets (PR-DP) 
lhat tunnel through at least part of said mobile 
data packet network (GPRS-SYSTEM) public 
data packets (PU-DP) sent from an originating 
lerminal (TE) over a public data packet nelwork is 
(INTERNET) and said mobile dala packet net- 
work (GPRS-SYSTEM) to at least a plurality of 
mobile stalions (MS2, MS3) within said service 
area; and 

b. means (COPY/SEND) to generate copies of so 
said public data packets (PU-DP) and to send 

a copy to each one of said mobile stations 
(MS2 ; MS3). 

7. Service node (SGSN3) according to claim 6, 2e 

CHARACTERISED IN THAT said service 
node (SGSN3) further comprises: 



ets (PR-DP) being adapted to tunnel public data 
packets (PU-DP) sent from an originating terminal 
(TE) over a public data packet network (INTERNET) 
and said mobile data packel network (GPRS-SYS- 
TEM) to at least a plurality of mobile stalions (MS1 , 
MS2, MS3, MS4 : MSG), 

CHARACTERISED IN THAT said routing 
node (DPR1 DPR2, DPR3, DPR4 ; DPR5, DPR6) 
comprises means to multi-cast said private data 
packets (PR-DP) by means of a private multi-cast 
address (PR-MCA) in an overhead section (PR-H) 
of said private dala packets (PR-DP). 



c. private join/leave message receiving means 
(PR-JN/LV RX) adapted to receive a private so 
join/leave message indicating that a mobile sta- 
tion (MS2) wants to join/leave a public multi- 
cast group; and 

d. registration means (MS-REGISTRATION), 
coupled to said privalQ join/leavQ message re- 35 
ceiving means (PR-JN/LV RX), and adapted to 
register inclusion and deletion of a mobile sta- 
tion (MS2). 



8. Service node (SGSN3) according to claim 6, 40 
CHARACTERISED IN THAT said service 
node (SGSN3) further comprises: 



e. GPRS join/leave message receiving means 
1o receive a GPRS message indicating that a 45 
mobile stalion (MS2) wants to join/leave a pub- 
lic multi-cast group; and 
1. registration means (MS-REGISTRATION) 
coupled to said GPRS join/leave message re- 
ceiving means and adapted to register inclu- so 
sion and deletion of said mobile station (MS2) 
1o or from said public multi-cast group. 



9. Routing node (DPR1 , DPR2, DPR3, DPR4, DPR5 : 
DPR6) for routing private data packets (PR-DP) 55 
from a gateway node (GGSN1 ) to at least one serv- 
ice node (SGSN 1 , SGSN3) of a mobile data packet 
network (GPRS-SYSTEM), said private data pack- 
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Description 

Background of 1he Invention 

[0001] This inversion relates to determining an end 
point of a generic routing encapsulation ("GRE") tunnel. 
[0002] GRE is a protocol that enables the encapsula- 
tion ot an arbitrary network layer protocol (Ihe payload 
protocol) by another arbitrary network layer protocol (the 
delivery protocol). GRE tunnels are virtual lunnels that 
are created on an intermediary network and that are 
used 1o transmit GRE -encapsulated data packets from 
a first nelwork to a second network. GRE tunnels are 
often used to create a virtual private network. ("VPN") 
by connecting Iwo remote local area networks ("LAN") 
via the Internet 

[0003] At one end of a GRE tunnel, a router receives 
a payload packet from the first network, and encapsu- 
lates the payload packet so that it conforms to the de- 
livery protocol of the intermediary network. The payload 
packet may be encapsulated in another packet or an 
Ethernet frame : for example. The encapsulated packet 
is transmitted through the intermediary network to the 
other end of the GRE tunnel. At thai end, a router de- 
encapsulates the packet, and transmits the payload 
packet to the second network. 

[0004] Heretofore, GRE tunnels were "static", mean- 
ing that the tunnel end points had to be configured, and 
updated, manually. For example, an address ol a router 
at one tunnel end point may change, thereby making it 
necessary to provide the new address to other routers 
thai use the tunnel end points. In a static GRE tunnel, a 
network administrator, using software such as Bay 
Command Console ("BCC") or Site Manager, enters this 
new information into each end point router manually. 
Manual reconfiguration is time-consuming and ineffi- 
cient. 

Summary of the Invenlion 

[0005] In one aspect, the invention determines an end 
point of a GRE tunnel (e.g., an address of an end point 
device) by receiving a data packet at the device, identi- 
fying the data packet as a GRE packet, and determining 
an address of the end point of the GRE tunnel using the 
data packet. The address of Ihe end point is stored in a 
table on the device. By determining an end point ad- 
dress using a GRE packet, the invention is able to pro- 
vide rouling updates automatically. 
[0006] This aspect may include one or more ol the fol- 
lowing features and/or functions. Identifying comprises 
searching a header ol the data packet for a value indic- 
ative of a GRE packet. The address ofthe end point com- 
prises a logical address of the end point. The device is 
a router, and ihe data packet is a routing update packet. 
[0007] Another aspect ol the invention is directed to 
obtaining an end point address of a GRE lunnel dynam- 
ically. In this aspect, a data packet is forwarded through 



the GRE tunnel to a remote GRE tunnel end point de- 
vice. In response, a reply is received from the remote 
GRE tunnel end point device, which includes a physical 
address of the remote GRE tunnel end point device. 

5 [0008] This aspect provides a way lor one device to 
obtain a physical address of a device at a remote tunnel 
end point. Thus, if end points have been added to, or 
removed from, the GRE tunnel, the invention can deter- 
mine this dynamically and roule packets accordingly. 

10 [0009] The foregoing aspect may include one or more 
of the following leatures and/or functions 
[0010] The aspect of the invention may be performed 
by a local GRE lunnel end point device, and a table on 
the local GRE tunnel end point device may be updated 

is to include the physical address ol the remote GRE tun- 
nel end point device. The reply includes a unicast ad- 
dress of the remote GRE lunnel end point device. The 
data packet comprises an address resolution protocol 
packet (ARP), and the ARP packet includes a logical 

20 address ofthe remote GRE tunnel end point device. The 
reply comprises a GRE-encapsulated data packet with 
the physical address of the remote GRE lunnel end point 
device as a payload. 

[0011] This summary has been provided so that the 
2S nature of the invention can be understood quickly. Ade- 
tailed description of illustrative embodiments of the in- 
vention is set forth below. 

Brief Description of the Drawings 

30 

[0012] FIG. 1 shows a nelwork system that includes 
three end point devices of a GRE tunnel. 
[0013] FIG. 2 is a flowchart showing a process exe- 
cuted at an end poinl device of the GRE tunnel to update 
35 routing information in other end point devices. 
[0014] FIG. 3 shows a routing update packet 
[0015] FIG. 4 shows a GRE header appended to the 
routing update packet. 

[0018] FIG. 5 shows an encapsulated routing update 
40 packet including an outer delivery protocol header 
[0017] FIG. 6 is a flowchart showing a process exe- 
cuted at an end point device to process a routing update 
packet. 

[0018] FIG. 7 is a diagram showing how packets are 
45 transmitted over the network syslem in one embodi- 
ment. 

[0019] FIG. 8 is a flowchart showing a process exe- 
cuted at a GRE tunnel end point device to oblain a phys- 
ical address of a remote end point device. 
50 [0020] FIG. 9 shows an Address Resolution Protocol 
("ARP") broadcast packet. 

[0021] FIG. 10showsaGREheaderappendedtothe 
ARP broadcast packet. 

[0022] FIG. 11 shows an encapsulated ARP broad- 
55 cast packet, including an outer delivery protocol header. 
[0023] FIG. 12, comprised of FIGs. 12a and 12b, is a 
flowchart showing a process executed at an end point 
device to process an encapsulated ARP broadcast 



2 



3 



EP 1 075 118 A2 



4 



packet and to provide a reply to the ARP broadcast 
packet. 

Description of the Preferred Embodiment 

[0024] Referring to FIG. 1, a network system 10 is 
shown which includes devices 12, Hand 16, local area 
networks ("LANs") 18 to 20, and intermediary nelwork 
22. 

[0025] Intermediary network 22 may be any type of 
nenvork, such as a wide area network ("WAN") or the 
Internet, that supports IPv4 (Internet Protocol version 
4), IP multicast routing, and IGMP (Internet Group Mul- 
ticast Protocol). Examples of protocols that may be used 
to perform multieast rouling are DVMRP (Distance Vec- 
tor Multicast Routing Protocol), MOSPF (Multicast Open 
Shortest-Path First), and PIM (Protocol Independent 
Multicasting). Packets may also be "unicasl" over inter- 
mediary network 22. Routes are distributed using pro- 
tocols, such as RIP (Rouling Information Protocol), 
OSPF (Open Shortest-Path First), and BGP (Border 
Gateway Protocol). 

[0026] Included on intermediary network 22 is GRE 
tunnel 24. Intermediary network 22 has no knowledge, 
per se, ol GRE tunnel 24. The GRE tunnel Is known only 
to the devices at its end points, namely devices 12 14 
and 1 6. GRE tunnel 24 passes encapsulated dala pack- 
ets between devices at tunnel end points 12, 14 and 16. 
Encapsulated packets may be sent to single, or multiple, 
tunnel end point devices. 

[0027] Devices 12, 14 and 16 are coupled to corre- 
sponding LANs IS to 20. Each of LANs 1 8 to 20 supports 
IPv4 and one or more of the foregoing routing protocols 
for transmiting data packets between devices on the 
LAN (e.g., personal computer {"PC") 29) and a GRE tun- 
nel end paint. Since both LANs 18 to 20 and intermedi- 
ary network 22 support IF, GRE encapsulation (de- 
scribed below) will be IP over IP. 
[0028] Eachtunnel hasamulticastaddress. Eachtun- 
nel end point device a physical IP address and a logical 
IP address. The logical IP address is an I P address that 
is statically configured over a GRE tunnel end point de- 
vice. The physical IP address is the network (IP) ad- 
dress of the end point device and is used by the delivery 
protocol to deliver dala packets through GRE tunnels to 
remole devices 

[0029] Devices 12, 14 and 16 are routers, or other 
computing devices, which receive data packels (either 
from a GRE tunnel or a LAN) and which forward the data 
packels to their intended destinations (either via a GRE 
tunnel or on the LAN). For example, "local" device 12 
receives payload data packets from PC 29 on LAN 18 
and lorwards those packels to "remole" device 14 via 
GRE tunnel 24. Similarly, device 12 receives packets 
from GRE tunnel 24 and forwards those packets onto 
LAN 1 8. Whether a device is local or remote is a matter 
of perspective only. For example, to device 14, devices 
12 and 16 are remote. 



[0030] Each device 1 2, 14 and 1 6 includes a memory 
13 for storing computer instructions, and a processor 
1 2a for executing those instructions to perform various 
functions, as shewn in blown-up view 30. For example, 

5 routing instructions 1 3c cause device 1 2 to forward rout- 
ing packets in accordance with one or more of the rout- 
ing protocols noted above. Dynamic GRE instructions 
13b process GRE -encapsulated routing packets trans- 
mitted over GRE tunnel 24. 

f [0031] Memory 13 also stores an address table 13a 
and a rouling table 13d. In this regard, each device has 
several associated addresses. For example, device 12 
has an address 35 which includes a logical IP address 
35a of "200.10 1.1", and a physical IP address 35b of 

is "192.115.65.12". The multicast address 35c 
("232.10.5.1") of GRE tunnel 24 is also shown, as are 
addresses of devices 14 and 16. 
[0032] Routing table 1 3d stores network rouling infor- 
mation, including the logical IP addresses of devices 12, 

20 1 A, and 1 6. Routing table 1 3d is used by routing instruc- 
tions 1 3c 1o route packels Address table 1 3a stores the 
physical IP addresses of devices 12, 14 and 16 which 
map to corresponding logical I P addresses in routing ta- 
ble 13d. 

25 [0033] If address table 1 3a needs to be updated with 
the physical IP address ol devices 14 or 16, or if a log- 
ical/physical IP address mapping of device 12 needs to 
be updaled in devices 14 and 16, dynamic GRE instruc- 
tions 13b are execuled. Dynamic GRE instructions 13b 

30 perform encapsulation and de-encapsulation, as de- 
scribed below. For broadcasl and multicasl packels, the 
destination IP address for such packets is a multicast 
address. For unicast packets, the destination address 
is a unicast address. 

35 

Determining a Device Logical Address 

[0034] Referring to FIG. 2, a process 40, implemented 
by computer instructions, is shown for updating routing 

40 tables in remote GRE tunnel end point devices. For il- 
lustration's sake, device 14 is designated as the local 
GRE tunnel end point device which executes computer 
instructions to implement process 40. 
[0035] Process 40 generates 42 a "routing update" 

45 packet 43 which holds network information 43a, includ- 
ing routing information such as the logical IP address of 
device 14 (see FIG. 3). Routing updates packets are 
multicast/broadcast packets (in the case ol RIP and 
OSPF) or unicast packets (in the case of BGP). 

so [0036] Process 40 appends a GRE header 44 to rout- 
ing update packet 43 (see FIG. 4). GRE header 44 in- 
cludes a protocol type field 44a that specifies the proto- 
col of packet 43, and a key present bit 44b lhat indicates 
if a tunnel key is enabled for the GRE tunnel. 

55 [0037] A tunnel key is an integer Irom "0" to "Offffffff" 
in GRE header 44. It specifies a unique tunnel identifier 
for each GRE tunnel. If a tunnel key is enabled, all out- 
bound traffic over a GRE lunnel will have the tunnel key 
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in its GRE header Inbound traffic over the GRE tunnel 
will be accepted only if the GRE tunnel key in the GRE 
header matches a tunnel key lhat is maintained in a 
memory on a tunnel end point device. Data packets that 
do not have the correcl tunnel key are discarded. 
[0033] Process 40 determines 45 whether to enable 
the tunnel key. If the tunnel key is enabled, process 40 
appends 46 a tunnel key and a GRE header with key 
present bit 44b set to " 1 " (to indicate that the tunnel key 
is enabled). If the tunnel key is not enabled, process 40 
appends 47 a GRE header with key present bit 44b set 
to "0" (to indicate lhat the tunnel key is not enabled). 
Tunnel keys need not be used in this embodiment 
[0039] Process 40 appends 48 an outer IP delivery 
header 50 to packet 49 (see FIG. 5). IP delivery header 
50 includes : as the destination address, a multicast ad- 
dress 50a of GRE tunnel 24. The IP delivery header in- 
cludes, as the source address, 1he physical IP address 
50b of device 14. The IP delivery header also includes 
a value in protocol field 50c to identify packet 54 as a 
GRE packet. 

[0040] Process 40 forwards 52 GRE-encapsulated 
routing update packet 54 (FIG. 5) to multicast address 
50a specified in IP delivery header 50. At each remote 
tunnel end poinl device 12 and 16, the data packet is 
processed. 

[0041] Referring to FIG. 6, a process 60 (in dynamic 
GRE instructions 1 3b) is executed by remote tunnel end 
point devices (from device 14's perspective), such as 
device 12, to handle routing updates received from de- 
vice 1 4. Process 60 receives 62 the encapsulated data 
packet 54, determines 64 if the packet is a GRE packet 
(il not, the packet may be otherwise processed 66), 
strips 68 the outer IP delivery header 50 off of the re- 
ceived data packet, and determines 70 if the tunnel key 
is enabled based on key presenl bit 44b If the tunnel 
key is enabled, process 60 compares 72 the tunnel key 
(not shown) in the packet to a tunnel key stored in its 
memory. II the two match 74 (or if a tunnel key was not 
enabled), process 60 strips 76 GRE header 44 from the 
packet 49, and reads 78 network information 43a from 
the packet. This network information 43a is slored in 
routingtable 13d of device 12. Thisprocess enablesdis- 
tribution of roules that are reachable through a logical 
IP address of a GRE tunnel end point at device 14. 

Obtaining a Device Physical Address 

[0042] Referring to FIGs. 7 and 8, a process 80 is ex- 
ecuted by instructions in device 1 2 to obtain Ihe physical 
IP address of device 14. To begin process 80 receives 
82 a payload packet 83 from PC 29 on LAN 18. The 
payload packet is addressed 1o a PC 85 on remote LAN 
1 9. Process 80 looks up a forwarding (delivery) address 
for PC 85 in routing table 1 3d. Based on the information 
in routing table 1 3d, process 80 determines that PC 85 
is located at the other end of a GRE tunnel 24. Process 
80 also determines the logical IP address of device 14 



from routing table 1 3d. Process 80 determines 86 if the 
physical address of device 14 is known. This is done by 
searching Ihrough address table 13a. 
[0043] If process 80 finds the physical IP address of 

5 device 14 in address table 13a, process 80 encapsu- 
lates 98 payload packet 83 (with a GRE header and out- 
er IP delivery header) and forwards 108 encapsulated 
payload packet 87 through GRE tunnel 24 to device 14. 
If the physical IP address of device 14 is not found in 

f address table 1 3a (or if device 1 2 has reason to believe 
that the address of device 14 has changed, e.g., due to 
network reconfiguration), process 80 determines 89 the 
physical IP address of device 14 dynamically. 
[0044] To determine 89 the physical IP address of de- 

is vice 14, process 80 generates 90 an ARP broadcast 
packet 141 (see FIG. 9). ARP broadcast packet 141 in- 
cludes the logical IP address 141a of device 14 as its 
payload. Process 80 encapsulates ARP broadcast 
packet 141 for transmission through GRE lunnel 24. 

so Process 80 appends a GRE header 1 42 to ARP broad- 
cast packet 141 (see FIG. 10). The GRE header 142 
includes a protocol type field 1 42a that specifies the pro- 
tocol of ARP broadcast packet 141 . For ARP, the proto- 
col type field is set to 0x806. GRE header 142 also in- 

2S eludes a key present bit 142b, which indicates if a tunnel 
key is required lor a GRE tunnel. A "0" in key present 
bit 142b indicates that no tunnel key is required and a 
"1 " in key present bit 1 42b indicates that a tunnel key is 
required. 

30 [0045] If Ihe tunnel key is enabled 92, process 80 ap- 
pends 94 Ihe GRE header and tunnel key and sets key 
present bit 1 42b to "1 "; otherwise it appends 96 the GRE 
header and sets key present bit 142b to "0". Process 80 
appends 98 an outer IP delivery header 144 to packet 

35 143 (see FIG. 11) to complete encapsulation. IP delivery 
header 144 includes, as the destination address, a mul- 
ticast address 144a of GRE tunnel 24. IP delivery head- 
er 144 includes, as the source address, the physical IP 
address 144b ol device 12. IPdeliveryheader144balso 

40 includes a value in a protocol field 144c which signifies 
that the packet is a GRE packet. 
[0046] Process 80 lorwards 100 the encapsulated 
ARP broadcast packet 145 (FIGs. 7 and 11 )1o multicast 
address 144a specified in IP delivery header 144. De- 

45 vice 14 (which is a member of the multicast group for 
the multicast address) receives encapsulated ARP 
broadcast packet 145 and processes it as described in 
FIG. 12 below. In response, device 14 forwards an en- 
capsulated ARP reply packet 146 (FIG. 7) to device 12, 

50 which includes the physical IP address of device 14. 
Process 80 receives 102 the ARP reply packet and 
reads the physical IP address of device 14. 
[0047] Process 80 updates 104 the address table 13a 
in device 12 1o include the physical IP address of device 

55 14. The physical IP address of device 14 is indexed to 
its logical IP address so that subsequent data packets 
can be lorwarded by referring to the address table. 
[0048] Once both the logical and physical IP address- 
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es of device 14 are known ; process 80 encapsulates CU 
106 the payload packet 83 and forwards 108 the encap- 
sulated payload packel 87 through GRE tunnel 24 to the 1. 
physical IP address ol device 14 (received in 102). En- 
capsulation 1 06 of the payload packet 83 is identical to 5 
the encapsulation process described above, except that 
the physical IP address of device 14 is used as the IP 
delivery header destination address instead of multicast 
address 144a. At device 14, the encapsulated packet 
87 is de-encapsula1ed and 1he de- encapsulated pay- JO 
load packet 147 is transmitted to PC 85. 
[0049] Referring to FIG. 12, a process 150 is shown 
by which device 1 4 determines whether to issue a reply 
to the encapsulated ARP broadcast packet 1 45 from de- 
vice^. JS 2. 
[0050] Process 150 receives 152 the encapsulated 
ARP broadcast packet 145from device 12 via GRE tun- 
nel 24. Process 150 determines 1 54, based on the value 
in the packet's protocol field 144c ; whether the data 
packet is a GRE packet. If the packet is not a GRE pack- so 
et, device 14 may use it in other processing 156. 3. 
[0051] If Ihe packet is a GRE packet, device 1 4 strips 
1 58 the I P delivery header 1 44 off the packet and reads 
the physical IP address 144b of device 12. Device 14 
also checks 160 (using the key present bit in the GRE 2S 4. 
header) whether a tunnel key has been enabled. If so, 
device 14 compares 162 the tunnel key inthedala pack- 
et to a tunnel key stored in its memory. If the tunnel keys 
do not match 164, process 150 discards 168 Ihe packet 
and relums. II the tunnel keys malch 164, or il it was so 
determined 160 that the tunnel key was not enabled, 5. 
process 150 strips 166 the GRE header 142 from the 
packel and reads 170 the logical IP address 141 a from 
the payload of the ARP broadcast packet. If the logical 
IP address 141 a from ihe ARP broadcast packet does 35 
not match 172 the logical address of device 14, the 6. 
packet is discarded 168. If the two malch, process 150 
prepares 174 an ARP reply packet which includes the 
physical I P (unicast) address ol device Has fls payload. 
[0052] The ARP reply packet is encapsulated 1 76 for 40 
transmission to device 1 2 over GRE tunnel 24. The en- 
capsulation process is similar to that described above. 
However, the physical IP address of device 12 (144b 
from encapsulated ARP broadcast packet 145) is used 
as the destination address in the IP delivery header of 45 7. 
encapsulated ARP reply packet 147. The encapsulated 
ARP reply packet 1 47 is lorwarded 1 78 to device 1 2 over 
GRE tunnel 24. Device 12 processes the reply packet 
as described in FIG. 6 above to read the physical IP ad- 8. 
dress ol device 1 4 therefrom. so 
[0053] Other embodiments are within the scope of the 
following claims. For example, the invention can be 
used with protocols and networks other than those de- 9. 
scribed above. In addition, the invention can be used on 
any type of nelworkable device, not just PCs and rout- 55 
ers. 

10, 



A method of obtaining an end point address of a 
generic routing encapsulation (GRE) tunnel, com- 
prising: 

forwarding a data packet through the GRE tun- 
nel to a remote GRE tunnel end point device, 
and 

receiving a reply from the remote GRE tunnel 
end point device, Ihe reply including a physical 
address of the remole GRE tunnel end point de- 
vice 

The melhod of claim 1, wherein the melhod is per- 
formed by a local GRE tunnel end point device, and 
further comprises updating atableon the local 
GRE tunnel end point device to include Ihe physical 
address of the remote GRE tunnel end point device. 

The method of claim 2, wherein the reply includes 
a unicast address of the remote GRE tunnel end 
point device. 

The method of claim 1 , wherein the data packet 
comprises an address resolution protocol (ARP) 
packet; and 

wherein the ARP packet includes a logical ad- 
dress of the remote GRE tunnel end poinl device. 

The method of claim 1 , wherein the reply comprises 
a GRE-encapsulated data packet with the physical 
address of the remote GRE tunnel end point device 
as a payload. 

A method of determining an end poinl of a generic 
routing encapsulation (GRE) tunnel, comprising: 

receiving a data packet at a device; 
identifying the data packel as a GRE packet; 
determining an address of the end point of the 
GRE tunnel using the data packet; and 
storing the address in a table on the device. 

The method of claim 5, wherein identifying compris- 
es searching a header ol the data packet for a value 
indicative of a GRE packel. 

The melhod ol claim 6, wherein the address of the 
end point comprises a logical address of the end 
point. 

The method of claim 6, wherein the device is a rout- 
er, and the data packel comprises a routing update 
packet. 

A computer program stored on a computer-reada- 
ble medium for obtaining an end point address of a 
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generic routing encapsulation (GRE) tunnel : the 
computer program comprising instructions that 
cause a computer to: 

lorward a data packet Ihrough the GRE tunnel 5 
to a remote GRE tunnel end point device; and 
receive a reply from the remote GRE tunnel end 
point device ; the reply including a physical ad- 
dress of the remote GRE tunnel end point de- 
vice. JO 

11. A computer program stored on a computer-reada- 
ble medium for determining an end point of a ge- 
neric routing encapsulation (GRE) tunnel, the com- 
puter program comprising instructions that cause a J£ 
computer to: 

receive a data packet at a device: 
identify the data packet as a GRE packet; 
determine an address of the end point of the 20 
GRE tunnel using the data packet; and 
store the address in a lable on the device. 

12. An apparatus for obtaining an end poinl address of 

a generic routing encapsulation (GRE) lunnel, the 2S 
apparatus comprising a processor which executes 
computer code to: 

lorward a data packet Ihrough the GRE tunnel 
to a remote GRE tunnel end point device; and so 
receive a reply from the remote GRE tunnel end 
point device, the reply including a physical ad- 
dress of the remote GRE tunnel end point de- 
vice 

35 

1 3. An apparatus for determining an end point ol a ge- 
neric routing encapsulation (GRE) tunnel, the ap- 
paratus comprising a processor which executes 
computer code to: 



dress, and 

wherein the second device issues a reply to the 
first device via the GRE tunnel, 1he reply includ- 
ing an address of the second device. 



is 



20 



30 



35 



receive a data packet at a device coupled to the 
processor; 

identify the data packet as a GRE packet, 
determine an address of the end point of the 
GRE tunnel using the data packet; and 45 
store the address in a cable on 1he device. 

14. A network system comprising: 

a firsl device in a multicast group; so 
a second device in the multicast group; and 
a generic routing encapsulation (GRE) tunnel 
configured over a network between a first end 
point at the first device and a second end point 
at the second device; 55 
wherein the first device forwards a data packet 
Ihrough Ihe GRE tunnel to devices in the mul- 
ticast group, the data packet requesting an ad- 



6 



EP 1 075 118 A2 




7 



EP 1 075 118 A2 



j GENERATE ROUTING UPDATE PACKET j ^ 




.46 



APPEND GRE HEADER, 
SET TUNNEL KEY PRESENT 
BIT TO 1, AND APPEND 
TUNNEL KEY 




APPEND GRE HEADER AND SET TUNNEL 
KEY PRESENT BIT TO 0 



1 

APPEND OUTER IP DELIVERY HEADER |/8 



FORWARD (MULTICAST) ENCAPSULATED y 
ROUTING UPDATE PACKET THROUGH 
TUNNEL 



52 



FIG. 2 



,43 



ROUTING UPDATE PACKET 
43a 



network information! 



FIG. 3 



GRE HEADER 



| protocol type [ 



44b 



key 
J present 
" bit 



ROUTING UPDATE PACKET 



43a network information 



FIG. 4 



8 



EP 1 075 118 A2 



50a 



,50b 

IP DELIVERY HEADER 



,50c 



1 

multicast 


physical IP 


r — 

protocol 


address 


address 


field 



44a 



GRE HEADER 
^protocol type 



44b 



key 
present 
bit 



ROUTING UPDATE PACKET 
network information / 3a 



FIG. 5 



9 



EP 1 075 118 A2 



62- [ RECEIVE DATA PACKET | 



60 



NO 



66 , 




OUTER PROCESSING 



IS THE 
PACKET A 

GRE 
.PACKET? 

YES 



64 



68 



STRIP OUTER IP DELIVERY HEADER OFF 
PACKET 



72 



COMPARE TUNNEL KEYS 



NO 







DISCARD PACKET 



76 



78 




vj STRIP GRE HEADER 



READ NETWORK INFORMATION 
AND STORE IN ROUTING TABLE 



FIG. 6 



10 



EP 1 075 118 A2 



I 1 

R « ! PAYLOAD ! 
0,5— i PACKET k_ 



-29 




LAN 



I ENCAPSULATED*" 1 
I ARP REPLY I 

L_PACK£T 1 

146 



[ DE-ENCAPSULATED 
PAYLOAD PACKET 



LAN 



19 



147 



FIG. 7 



PC 



85-T 



11 



EP 1 075 118 A2 



32 i -i 

RECEIVE PAYLOAD PACKET | 



DETERMINE LOGICAL iP ADDRESS OF REMOTE TUNNEL END POINT 




GENERATE ARP BROADCAST PACKET L 




APPEND CRE HEADER AND SET TUNNEL 
KEY TO PRESENT BIT TO 0 



APPEND GRE HEADER, SET 
TUNNEL KEY PRESENT BIT TO 1, 
AND APPEND TUNNEL KEY 



APPEND OUTER IP DELIVERY HEADER 



ENCAPSULATE 
PACKET 



FORWARD (MULTICAST) ENCAPSULATED ARP Y 
BROADCAST PACKET THROUGH TUNNEL 



RECEIVE REPLY FROM TUNNEL END POINT \ 



| | UPDATE ADDRESS TABLE~f '' t0 4 



ENCAPSULATE PACKET V 



FORWARD PAYLOAD PACKET THROUGH TUNNEL 



FIG. 8 



12 



EP 1 075 118 A2 



,141 



ARP BROADCAST PACKET 



141a logical IP address 



FIG. 9 



■143 



CRE HEADER 



j protocol type | ^ 



key 
present 
bit 



ARP BROADCAST PACKET 



141a logical IP address 



FIG. 10 



,144b 



145 



IP DELIVERY HEADER 



multicast physical IP 
address address 



protocol 
field 



GRE HEADER 



142a 

^protocol type 



142b 



key 
present 
bit 



142 



ARP BROADCAST PACKET 
logical IP address |J 41a 



FIG. 11 



13 



EP 1 075 118 A2 



152 RECEIVE DATA PACKET 



150 



NO 




158 



STRIP OUTER IP DELIVERY HEADER 
OFF PACKET 



156 



OTHER PROCESSING 



COMPARE TUNNEL KEYS 



NO 




FIG. 12A 



FIG. 12B 



FIG. 12 



FIG. 12A 



14 



EP 1 075 118 A2 




PREPARE REPLY PACKET, INCLUDING 
DEVICE PHYSICAL IP ADDRESS 



ENCAPSULATE 


i , 

REPLY PACKET ' 




> 


FORWARD REPLY PACKET THROUGH 
GRE TUNNEL 



FIG. 12B 



15 



(19) 



J 



Europaisches Patentamt 
European Patent Office 
Office europeen des brevets 



(12) 



(11) EP 1 213 943 A1 

EUROPEAN PATENT APPLICATION 



Dcits of publicst oni 


(51) Int CI. 7 : MU4U fioa 


ao nfi on no RiiiiAtin on n o/o /i 


/O H \ An nil at inn nnmhor fl1QnRQ07 H 
ytL I y rtfjpi L-dUUN IIUrilUK'. U UUDcfUr .3 




(22) Date of filing: 14.08.2001 




(84) Designated Contracting States: 


(72) Inventor: Patel, Sarvar 


AT BE CH CY DE DK ES Fl FR GB GR IE IT LI LU 


Montville, New Jersey 07045 (US) 


MC NL PTSETR 




Designated Extension States: 


(74) Representative: 


AL LT LV MK RO SI 


Buckley, Christopher Simon Thirsk et al 




Lucent Technologies NS UK Limited, 


(30) Priority: 11.12.2000 US 734148 


Intellectual Property Division, 




5 Mornington Road 


(71) Applicant: LUCENT TECHNOLOGIES INC. 


Woodford Green, Essex IG8 0TU (GB) 


Murray Hill, New Jersey 07974-0636 (US) 





CO 

0) 
CO 
OJ 

Q_ 

LU 



(54) Key conversion system and method 
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ond key value of a second communication system. For 
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ntermediate value from at least a portion of the first key 
value using a first random function. At least a portion of 
the first intermediate value is provided to a second ran- 
dom function to produce a second value. An exclusive- 
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ond intermediate value is provided to a third random 
function to produce a third value. By performing an ex- 
clusive-or on at least a portion of the third value and at 
least a portion of the first intermediate value, the key 
conversion system produces at least a first portion of 
the second key value, and at least a second portion of 
the second key value is produced as the second inter- 
mediate value. 
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Description 

BACKGROUND OF THE INVENTION 

1 . Field of The Invention 

[0001] The present invention relates to communica- 
tions; more specifically, the conversion of keys for first 
and second communications systems as the wireless 
unit roams between the first and second communica- 
tions systems. 

2. Description of Related Art 

[0002] FIG. 1 depicts a schematic diagram of first and 
second wireless communications systems which pro- 
vide wireless communications service to wireless units 
(e.g., wireless units 12a-c) that are situated within the 
geographic regions 14 and 16, respectively. A Mobile 
Switching Center (e.g. MSCs 20 and 24) is responsible 
for. among other things, establishing and maintaining 
calls between the wireless units, calls between a wire- 
less unit and a wireline unit (e.g., wireline unit 25), and/ 
or connections between a wireless unit and a packet da- 
ta network (PDN) such as the internet. As such, the 
MSC interconnects the wireless units within its geo- 
graphic region with a public switched telephone network 
(PSTN) 28 and/or a packet data network (PDN) 29. The 
geographic area serviced by the MSC is divided into 
spatially distinct areas called "cells." As depicted in FIG. 
1, each cell is schematically represented by one hexa- 
gon in a honeycomb pattern; in practice, however, each 
cell has an irregular shape that depends on the topog- 
raphy of the terrain surrounding the cell. 
[0003] Typically, each cell contains a base station (e. 
g. base stations 22a-e and 26a-e), which comprises the 
radios and antennas that the base station uses to com- 
municate with the wireless units in that cell. The base 
stations also comprise the transmission equipment that 
the base station uses to communicate with the MSC in 
the geographic area. For example, MSC 20 is connect- 
ed to the base stations 22a-e in the geographic area 14. 
and an MSC 24 is connected to the base stations 26a- 
e in the geographic region 16. Within a geographic re- 
gion, the MSC switches calls between base stations in 
real time as the wireless unit moves between cells, re- 
ferred to as call nan doff. Depending on the embodiment, 
a base station controller (BSC) can be a separate base 
station controller (BSC) (not shown) connected to sev- 
eral base stations or located at each base station which 
administers the radio resources for the base stations 
and relays information to the MSC. 
[0004] The MSCs 20 and 24 use a signaling network 
32, such as asignaling network conforming to thestand- 
ard identified as TIA/EIA-41-D entitled "Cellular Radio- 
telecommunications Intersystem Operations," Decem- 
ber 1997 ("IS-41"), which enables the exchange of in- 
formation about the wireless units which are roaming 



within the respective geographic areas 14 and 16, For 
example, a wireless unit 12a is roaming when the wire- 
less unit 12a leaves the geographic area 14 of the MSC 
20 to which it was originally assigned (e.g. home MSC). 

5 To ensurethata roaming wireless unit can receive acall, 
the roaming wireless unit 12a registers with the MSC 24 
in which it presently resides (e.g., the visitor MSC) by 
notifying the visitor MSC 24 of its presence. Once a 
roaming wireless unit 12a is identified by a visitor MSC 

'0 24, the visitor MSC 24 sends a registration request to 
the home MSC 20 over the signaling network 32, and 
the home MSC 20 updates a database 34, referred to 
as the home location register (HLR), with the identifica- 
tion of the visitor MSC 24, thereby providing the location 

'5 of the roaming wireless unit 12a to the home MSC 20 
[0005] After a roaming wireless unit is authenticated, 
the home MSC 20 provides to the visitor MSC 24 a cus- 
tomer profile which indicates the features available to 
the roaming wireless unit, such as call waiting, caller id, 

20 call forwarding, three-way calling, and international di- 
aling access. Upon receiving the customer profile, the 
visitor MSC 24 updates a database 36, referred to as 
the visitor location register (VLR), to provide the same 
features as the home MSC 20, The HLR, VLR and/or 

25 the authentication center (AC) can be co-located at the 
MSC or remotely accessed. 

[0006] If a wireless unit is roaming between wireless 
communications systems using different wireless com- 
munications standards, providing the wireless unit with 

30 the same features and services in the different wireless 
communications systems is complex if even feasible. 
There are currently different wireless communication 
standards utilized in the U.S., Europe, and Japan. The 
U.S, currently utilizes two major wireless communica- 

35 tions systems with differing standards. The first system 
is a time division multiple access system (TDMA) and is 
governed by the standard known as S 136, the second 
system is a code division multiple access (CDMA) sys- 
tem governed by the standard known as IS-9S. Both 

40 communication systems use the standard known as IS- 
41 for intersystem messaging, which defines the au- 
thentication procedure. 

[0007] In TDMA, users share a frequency band, each 
user's speech is stored, compressed and transmitted as 

45 a quick packet, using controlled time slots to distinguish 
them, hence the phrase "time division". At the receiver, 
the packet is decompressed. In the IS-136 protocol, 
three users share a given carrier frequency. In contrast, 
CDMA uses a unique code to "spread" the signal across 

so the wide area of the spectrum (hence the alternative 
name - spread spectrum), and the receiver uses the 
same code to recover the signal from the noise. A very 
robust and secure channel can be established, even for 
an extremely low-power signal. Further, by using differ- 

55 ent codes, a number of different channels can simulta- 
neously share the same carrier signal without interfering 
with each other. Both CDMA and TDMA systems are 
defined for a Second Generation (2G) and Third Gen- 
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eration (3G) phases with differing requirements for user 
nformation privacy or confidentiality, 
[0008] Europe utilizes the Global System for Mobiles 
(GSM) network as defined by the European Telecom- 
munications Standard Institute (ETSI). GSM is aTDMA 
standard, with 8 users percarrierfrequency. Thespeech 
is taken in 20 msec windows, which are sampled, proc- 
essed, and compressed. GSM is transmitted on a 900 
MHz carrier. There is an alternative system operating at 
1 .8 GHz (DCS 1 800), providing additional capacity, and 
is often viewed as more of a personal communication 
system (PCS) than a cellular system. In a similar way, 
the U.S. has also implemented DCS-1900, another 
GSM system operating on the different carrier of 1 .9 
GHz. Personal Digital Cellular (PDC) is the Japanese 
standard, previously known as JDC (Japanese Digital 
Cellular). PDC is a TDMA standard similar to the U.S. 
standard known as IS-54 protocol. 
[0009] The GSM network utilizes a removable user 
identification module (UIM) which is a credit card size 
card which is owned by a subscriber who slides the UIM 
into any GSM handset to transform it into "their" phone. 
It will ring when their unique phone number is dialed, 
calls made will be billed to their account; all options and 
services connect; voice mail can be connected and so 
on. People with different UIMs can share one "physical" 
handset, turning it into several "virtual" handsets, one 
per UIM. Similarto the U.S. systems, the GSM network 
also permits "roaming", by which different network op- 
erators agree to recognize (and accept) subscribers 
from other wireless communications systems or net- 
works, as wireless units (or UIMs) move. So, British sub- 
scribers can drive through France or Germany and use 
their GSM wireless unit to make and receive calls (on 
theirsame UK number), with as much ease as an Amer- 
ican businessman can use a wireless unit in Boston, Mi- 
ami, or Seattle, within anyone of the U.S. wireless com- 
munications system. The GSM system is defined as a 
Second Generation (2G) system. 
[0010] The third generation (3G) enhancement of the 
GSM security scheme is defined in the Universal Mobile 
Telecommunications Service (UMTS) set of standards, 
and specifically forthe security in the standard identified 
as 3GPP TS-33.102 "Security Architecture" specifica- 
tions. This security scheme with slight variations will be 
used as a basis for the worldwide common security 
scheme for all 3G communications systems, including 
UMTS, TDMA, and CDMA. 

[0011] The 2G GSM authentication scheme is illus- 
trated in FIG, 2. This authentication scheme includes a 
home location register (HLR) 40, a visiting location reg- 
ister (VLR) 50, and a wireless unit or mobile terminal 
(MT) 60, which includes a UIM 62. When the mobile ter- 
minal 60 places a call, a request is sent to the home 
location register 40, which generates an authentication 
vector AV, also called "triplet" (RAND, SRES, K c ) from 
a root key K;, The triplet includes a random number 
RAND, a signed response SRES, and a session key K c . 



The triplet is provided to thevisiting location register 50, 
which passes the random number RAND to the mobile 
terminal 60. The UIM 62 receives the random number 
RAND, and utilizing the root key K j: the random number 
5 RAND, and an algorithm A3, calculates a signed re- 
sponse SRES. The UIM 62 also utilizes the root key K, 
and the random number RAND, and an algorithm A8 to 
calculate the session key K c . The SRES, calculated by 
the UIM 62, is returned to the visiting location register 
'0 50, which compares this value from the SRES received 
from the home location register 40, in order to authen- 
ticate the subscriber using the mobile terminal 30. 
[0012] In the GSM "challenge/response" authentica- 
tion system, the visiting location register 50 never re- 
's ceives the root key K, being held by the UIM 32 and the 
home location register 40. The VLR 50 also does not 
need to know the authentication algorithms used by the 
HLR 40 and UIM 62, Also, in the GSM authentication 
scheme, the triplet must be sent for every phone call by 
20 the home location register 40. RAND is 128 bits, SRES 
is 32 bits, and K c is 64 bits, which is 224 bits of data for 
each request, which is a significant data load. The main 
focus of this description is the 64 bits long K c session 
ciphering key which is used for user information confi- 
25 dent al ty. When the mobile terminal roams into another 
serving system while in the call, the session key Kq is 
forwarded from the old VLR to the new target serving 
system. 

[0013] FIG. 3 shows the UMTS security scheme 
30 which is an enhancement to the 2G GSM scheme. Sim- 
ilar to the GSM scheme, when the mobile terminal 90 
places a call, a request is sent to the home location reg- 
ister 70, which sends an authentication vector - AV to 
the Visited Location Register (VLR) 80 which contains 
35 five elements instead of the three elements of a triplet, 
and therefore is called "quintuplet". This vector contains 
the 128 bit RAND, the 64 bits SRES, the AUTN value 
which carries the authentication signature of the home 
network, and two session security keys: the 128 bit ci- 
40 phering key CK and the 1 28 bit integrity key IK, These 
latter two keys, CKand IK, are the focus of this descrip- 
tion, 

[0014] The vector is provided to the visiting location 
register 80, which passes the random number RAND 

45 and the AUTN to the mobile terminal 90. The UIM 92 
receives the random number RAND, and utilizing the 
root key Kj, the random number RAND, and an defined 
algorithmic functions, validates the AUTN and calcu- 
lates asigned response SRES. The UIM 92 also utilizes 

so the root key K; and the random number RAND and de- 
fined algorithmic functions to calculate the session keys 
CK and IK. The SRES, calculated by the UIM 92, is re- 
turned to the visiting location register 80, which com- 
pares this value from the SRES received from the home 

55 location register 70 in order to authenticate the subscrib- 
er using the mobile terminal 90. A focus of this descrip- 
tion are the 128 bits long session ciphering key CK and 
128 bits long session integrity key IK which are used for 
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user information confidentiality and session integrity 
protection. Once the subscriber is successfully authen- 
ticated, the VLR 80 activates the CK and IK received in 
this authentication vector. If the mobile terminal roams 
into another serving system while on the call, the CK 
and IK are sent to the new target serving system. 
[0015] The 2G IS-41 authentication scheme, used in 
U.S. TDMAand CDMA systems, is illustrated in FIG. 4. 
This authentication scheme involves a home location 
register (HLR) 100, a visiting location register (VLR) 
110, and a mobile terminal (MT) 120, which can include 
a UIM 122. The root key ; known as the A_key : is stored 
only in the HLR 100 and the UIM 122. There is a sec- 
ondary key, known as Shared Secret Data SSD, which 
is sentto the VLR 1 1 0 during roaming. SSD is generated 
from the A_key using a cryptographic algorithm. The 
procedure for generating the SSD is described else- 
where and is known to those skilled in the art. When the 
MT 1 20 roams to a visiting network, the VLR 110 sends 
an authentication request to the HLR 100, which re- 
sponds by sending that subscriber's SSD. Once the VLR 
110 has the SSD it can authenticate the MT 120 inde- 
pendently of the HLR 1 00 : or with the assistance of the 
HLR 1 00 as is known to those skilled in the art. The VLR 
110 sends a random number RAND to the UIM 122 via 
the MT120, and the UIM 122 calculates the authentica- 
tion response (AUTHR) using RAND and the stored val- 
ue of SSD in UIM 122. AUTHR is returned to the VLR 
11 0, which checks it against the value of AUTHR that it 
has independently calculated in the same manner. If the 
two AUTHR values match, the MT 120 is declared valid. 
This process repeats when the wireless unit attempts to 
access the system, for instance, to initiate a call, or to 
answer a page when the call is received. 
[0016] In these cases, the session security keys are 
also generated. To generate session security keys, the 
nternal state of the computation algorithm is preserved 
after the authentication calculation. Several session se- 
curity keys are then calculated by the UIM 122 and the 
VLR 110 using the current value of SSD. Specifically, 
the 520 bits Voice Privacy Mask (VPM) is computed, 
which is used for concealing the TDMA speech data 
throughout the call. This VPM is derived at the beginning 
of the call by the UIM and VLR, and, if the mobile roams 
into another serving system during the call, the VPM is 
sent to the new serving system by the VLR. When the 
call is concluded, the VPM is erased by both the UIM 
and the serving VLR. Likewise, the 64 bits Signaling 
Message Encryption Key (SMEKEY) is computed, 
which is used for encrypting the TDMA signaling infor- 
mation throughout the call. This SMEKEY is derived at 
the beginning of thecal! by the UIM and VLR. and. if the 
mobile roams into another serving system during the 
call the SMEKEY is sentto the new serving system by 
the VLR. When the call is concluded, the SMEKEY is 
erased by both the UIM and the serving VLR. 
[0017] The 2G CDMA scheme uses a similar method 
of key distribution, except, instead of the 520 bits VPM, 



it is using the 42 Least Significant Bits (LSB) of the VPM 
as a seed into the Private Long Code Mask (PLCM). 
This PLCM is used as an additional scrambling mask 
for the information before its spreading. The 42-bit 

5 PLCM is consistent throughout the call and is sent to the 
new serving system by the VLR if the mobile roams into 
another serving system. The SMEKEY is used in the 
same way as in the TDMA based scheme, 
[0018] The IS-41 3G security scheme uses the UMTS 

w security scheme, which is based on the delivery of the 
128-bits ciphering key CK and 128-bits integrity key IK 
to the visited system VLR, while the same keys are com- 
puted by the UIM. 

[0019] Key conversions as a wireless unit roams be- 
'5 tween communications systems should be performed in 
a way that even if lower security of 2G schemes and 
algorithms is compromised and partial keys are recov- 
ered by the intruder, the 3G session keys would still 
maintain the same level of security. Such conversions 
20 will allow a subscriberto "roam globally" maintaining the 
security of communications data and integrity of com- 
munications session. 

SUMMARY OF THE INVENTION 

25 

[0020] The present invention is a key conversion sys- 
tem for deterministically and reversibly converting a first 
key value of a first communications system into a sec- 
ond key value of a second communication system. For 
30 example, the key conversion system generates a first 
intermediate value from at least a portion of the first key 
value using a first random function. At least a portion of 
the first intermediate value is provided to a second ran- 
dom function to produce a second value. An exclusive- 
35 or is performed on at least a portion of the first key value 
and at least a portion of the second value to generate a 
second intermediate value. At least a portion of the sec- 
ond intermediate value is provided to a third random 
function to produce a third value. By performing an ex- 
40 clusive-or on at least a portion of the third value and at 
least a portion of the first intermediate value, the key 
conversion system produces at least a first portion of 
the second key value, and at least a second portion of 
the second key value is produced as the second inter- 
ns mediate value. The key conversion system is determin- 
istic in that, given a first key value, a wireless unit and 
the wireless communications system will determine the 
same second key value without requiring an exchange 
of information. 

so [0021 ] The key conversion system is reversible or bi- 
directional in that, if the wireless unit is handed off back 
to the first communications system, the second key val- 
ue of the second communications system is converted 
back to the first key value of the first communications 

55 system. For example, the key conversion system pro- 
vides the at least second portion of the second key value 
to the third random function to produce the third value. 
The first intermediate value is generated by performing 
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an exclusive-or on the first portion of the second key 
value and the third value. Using the second random 
function, the key conversion system generates the sec- 
ond valuefrom thefirst intermediate value and produces 
at least a portion of thefirst key by performing an exclu- 
sive-or on the second value and the second portion of 
the second key value. The key conversion system pro- 
vides improved security because even if almost all of 
the second key value is known, the first key value cannot 
easily be recovered. Similarly, if almost all of thefirst key 
value is known, the second key value is not easily re- 
covered. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0022] Other aspects and advantages of the present 
nvention may become apparent upon reading the fol- 
lowing detailed description and. upon reference to the 
drawings in which 

FIG. 1 shows a general diagram of wireless com- 
munications systems for which the key conversion 
system according to the principles of the present in- 
vention can be used; 

FIG. 2 is a block diagram illustrating the basic com- 
ponents of the prior art 2G global system for mobiles 
(GSM) network and security messages transmitted 
in the 2G GSM network; 

FIG. 3 is a block diagram illustrating the basic com- 
ponents of the prior art 3G UMTS network and mes- 
sages transmitted in the 3G UMTS network: 
FIG. 4 is a block diagram illustrating the basic com- 
ponents of the prior art 2G IS-41 network and mes- 
sages transmitted in the prior art 2G IS-41 network: 
FIG. 5 is a block diagram illustrating how a user 
roams from a 2G TDMA network into a generic 3G 
network: 

FIG. 6 is a block diagram illustrating how a user 
roams from a generic 3G network into a 2G TDMA 
network; 

FIG. 7 is a block diagram illustrating how a user 
roams from a 2G CDMA network into a generic 3G 
network; 

FIG. B is a block diagram illustrating how a user 
roams from a generic 3G network into a 2G CDMA 
network; 

FIG. 9 is a block diagram illustrating how a user 
roams from a 2G GSM network into a generic 3G 
network: 

FIG. 10 is a block diagram illustrating how a user 
roams from a generic 3G network into a 2G GSM 
network; 

FIG. 11 is a flow diagram of an embodiment of the 
forward conversion for the key conversion system 
according to principles of the present invention ; and 
FIG. 12 is a flow diagram of an embodiment of the 
reverse conversion for the key conversion system 
according to principles of the present invention 



DETAILED DESCRIPTION 

[0023] An illustrative embodiment of the key conver- 
sion system according to the principles of the present 
5 invention is described below which provides an im- 
proved key conversion for a wireless unit which roams 
between first and second wireless communications sys- 
tems. The key conversion system deterministically and 
reversibly converts an m bit key value of a first commu- 
te nications system into an n-bit key value of a second 
communication system. In certain embodiments, the 
key conversion system use three random functions f, g 
and h where random functions f and g map an m bit input 
string into an n-m bit string resembling a random 
'5 number, and the random function h maps an n-m bit 
string into an m bit string resembling a random number. 
A random function maps inputs to outputs such that the 
outputs are unpredictable and random looking given the 
input. In the embodiments described below, the random 
20 functions are random oracles where every time an input 
is given it maps to the same output. Additionally, in the 
embodiments described below, the random functions 
are publicly known. For example, the random functions 
are known by the wireless communications system(s) 
25 involved in the intersystem handoff and the wireless 
unit. 

[0024] The key conversion system is deterministic in 
that, given an m-bit key value, a wireless unit and the 
wireless communications system will determine the 

30 same n-bit key value without requiring an exchange of 
information. The key conversion system is reversible or 
bi-directional in that, if the wireless unit is handed off 
back to the first communications system, the n bit key 
of the second communications system is converted 

35 back to the m-b it key of the f i rst comm unications system . 
The key conversion system provides improved security 
because even if almost all of the n bit key value is known, 
the m bit key value cannot easily be recovered. Similarly, 
if almost all of the m bit key value is known, the n bit key 

40 value is not easily recovered. 

[0025] Depending on the embodiment, the key con- 
version system can provide secure, deterministic and 
bi-directional key conversion when a wireless unit 
roams between two wireless communications system, 

45 such as between an older communications system and 
a newer communications system. For example where 
the same reference numerals indicate like components, 
the IS-41 3G security scheme of FIG. 5 converts, at the 
VLR 80 and at the wireless unit 120 (or 1 22), the520-bits 

so VPM in combination with the 64-bits SM EKEY received 
from the VLR 110 to the 128-bit CK and/or 128-bit IK 
when the wireless unit roams into the 3G system from 
the 2G TDMA system. Conversely, as shown in FIG. 6, 
the IS-41 3G security scheme converts, at the VLR 80 

55 and the wireless unit 90 (or 92), the 128-bit CK and/or 
the 128-bit IK to the 520-bits VPM in combination with 
the 64-bits SM EKEY when the wireless unit roams into 
the 2G TDMA system from the 3G system. The VLR 80 
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provides the VPM and the SMEKEY to the VLR 110. 
[0026] As shown in FIG. 7, IS 41 3G security scheme 
converts, at the VLR 80 and at the wireless unit 1 20 (or 
122), the 42-bits PLCM in combination with the 64-bits 
SMEKEY received from the VLR 11 0 to the 128-bit CK 
and/or the 128-bit IK when the wireless unit roams into 
the 3G system from the 2G CDMA system. Conversely, 
as shown in FIG. 8, the IS-41 3G security scheme con- 
verts, at the VLR 80 and at the wireless unit 90 (or 92), 
the 128-bit CK and 128-bit IK to the 42-bits PLCM in 
combination with the 64-bits SMEKEY when the mobile 
roams into the 2G CDMA system from the 3G system. 
The VLR 80 provides the PLCM and the SMEKEY to the 
VLR 110. 

[0027] As shown in FIG. 9. the UMTS 3G security 
scheme converts, at the VLR 80 and at the wireless unit 
60 (or 62), the 64-bit Kq received from the VLR 50 to the 
128-bit CK and/or the 128-bit IK when the wireless unit 
roams into the 3G UMTS system from the 2G GSM sys- 
tem. Conversely, as shown in FIG. 10, the UMTS 3G 
security system converts, at the VLR 80 and at the wire- 
less unit 90(or 92), the 128-bit CK and/or the 128-bit IK 
to the 64-bit K c when the wireless unit roams into the 
2G GSM system from the 3G UMTS system. The VLR 
80 provides the K c to the VLR 50. 
[0028] Accordingly, in certain embodiments, a wire- 
less unitthatsupports enhanced subscriber authentica- 
tion (ESA) and enhanced subscriber privacy (ESP) in a 
first communications system, such as a newer 3G com- 
munications system, may implement multiple privacy 
modes to enable the wireless unit to provide privacy us- 
ng older algorithms in a second communications sys- 
tem, such as an older 2G TDMA communications sys- 
tem. Such a wireless unit can provide other forms of pri- 
vacy after intersystem handoff to an MSC for an older 
second communications system that does not support 
ESP. When handoff to the older second communications 
system is required, the key conversion system can con- 
vert the key values for the newer first communications 
system to the privacy keys needed for the older privacy 
algorithms supported by the older second communica- 
tions system. The keys for the second communications 
system can be sent to the target MSC of the second 
communications system from the MSC of the first com- 
munications system. Since the key conversion system 
is deterministic, the wireless unit will also have the keys 
for the second communications system by performing 
the same conversion as the first communication system 
using the key conversion system of the present inven- 
tion. 

[0029] The key conversion system maps a key(s) 
from a first system into a key(s) of a second system and 
back again. For example, when performing an intersys- 
tem handoff between a 3G communications system and 
a 2G TDMA system, the key conversion system can 
map a cipher key CK into a VPM ASK/SM EKEY (VS) 
pair. In this embodiment, the key conversion function 
possesses the following properties: 1) A 128 bit CK is 



mapped into a 584 bit VS; 2) The function is reversible 
and maps back a 584 bit VS into a 128 bit CK; and 3) 
The function is secure in the sense that partial knowl- 
edge of the 584 bit key will not allow the adversary to 

5 recovertheCK, nor will partial knowledge of 128 bit key 
CK allow the adversary to recover the 584 bit VS. In cer- 
tain instances, for example when the call originates in a 
first communication system having a larger key value 
than the target second communications system, the 

w conversion system maps the key value of the first com- 
munication system to a key value of a second commu- 
nications system. However, if the wireless unit returns 
to the first communications system, the key conversion 
system maps the second key value to a subsequent key 

'5 value for the first communications system which is not 
necessarily the same as the original key value. Subse- 
quent handoffs back to the first communications system 
from the second communications system produce a key 
value which is the same as the subsequent key value, 

20 [0030] For example, when performing an intersystem 
handoff for a call originating with a 2G TDMA system to 
a 3G system, the key conversion system can map VP- 
MASK/SMEKEY (VS) pair into a cipher key CK. In this 
embodiment, the key conversion function maps the 584 

25 bit VS into the 128 bit CK. If the wireless unit is handed 
back to the 2G TDMA system, the conversion system 
maps back the 128 bit CK into the 584 bit VS, but the 
new 584 bit VS may not be the same as the original 584 
bit VS. Subsequent handoffs to the 2G TDMA system 

30 from the 3G system will maintain the new 584 bit VS. 
Although this should not effect the security or operation 
of the wireless unit, the 128 bit CK is maintained the 
same all along in this embodiment. 
[0031 ] In this embodiment, the key conversion system 

35 includes conversion functions available at the MSC in 
the newer system and at the wireless unit which will con- 
vert key values, for afirst communications system, such 
as ESP keys, into key values of a second communica- 
tions system, such as keys used for older privacy algo- 

40 rithms. In this example, the conversion function should 
convert the 128 bit CK key in the new first communica- 
tion system to VPMASK/SMEKEY (VS) keys forthe old- 
er second communication system, VPMASK is com- 
posed of 260 bits mask for each direction and SMEKEY 

45 i s 64 bits long, for a total of 584 bits to be used by the 
older communication system. In case of an intersystem 
handoff from the old communication system to the new 
communication system, it may be useful for the conver- 
sion function to be reversible. The old communication 

so system does not know about the new communication 
system and will transfer all 584 bits to the new commu- 
nication system. The new communication system upon 
receiving the 584 bit key will realize that it needs to re- 
cover the 128 bit CK, and hence will compute the CK 

55 from the 584 bit key. 

[0032] The VS keys created at the wireless unit and 
the MSC should be the same. This means the calcula- 
tion of the VS keys must be based solely on CK and any 
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other quantities known by both the MSC and the wire- 
less unit. Otherwise, any new quantities (e.g. random 
number) would have to be exchanged between the wire- 
less unit and the MSC prior to the conversion. The key 
conversion system does not require the exchange of in- 
formation between the wireless unit and the new MSC 
anddeterministicallymapsaCKto VS keys and VS keys 
to a CK key. 

[0033] Additionally, weaknesses in the old communi- 
cations system should not make the new communica- 
tions system weak. One can achieve this by making the 
key conversion function cryptographically one way. so 
that even if the entire key of the old communication sys- 
tem, such as the VS key in this example, is revealed, 
the adversary cannot recover the key of the new com- 
munication system, such as the CK key in this example. 
However, this will make the system non-reversible and, 
as previously noted, the key conversion system should 
be reversible, Nevertheless, the key conversion system 
can be reversible and still provide almost all of the se- 
curity of a non-reversible function. The security of the 
key conversion system in this example prevents an ad- 
versary from recovering any part of the CK key even if 
almost all of the VS key is revealed except a small part. 
The adversary can guess the small part, but he should 
not be able to do any better. This aspect is important 
because parts of VPMASK may be somewhat easy to 
recover, and the entire VPMASK may be easier to re- 
cover than the SMEKEY. Yet if some part of the old sys- 
tem is hard to recover than the adversary will not know 
anything about CK. A similar security can apply to CK 
so that a partial knowledge of CK should not tell the ad- 
versary anything about VS. 

[0034] In certain embodiments, the conversion func- 
tion has two modes l the forward conversion and the re- 
verse conversion. In the example of roaming from the 
3G communications system to the 2G TDMA communi- 
cations system, the forward conversion takes the 128 
bit randomly created CK key and expands it to 584 bit 
VS key, The reverse conversion function takes the 584 
bit VS keys and maps it to a 1 28 bit CK key, In this em- 
bodiment, the forward conversion function is composed 
of 3 random functions f, g and h which map a given input 
into a random output. In this embodiment, these are not 
secret functions but public random functions known to 
everybody, including the adversary. These public ran- 
dom functions are referred to as random oracles in the 
literature. These random oracles can be implemented 
using hash functions and block ciphers as described be- 
low. In this example, the three random functions are f, 
g. h where f and g map a 128 bit input into a 456 bit 
random value, and h maps a 456 bit input into a 1 28 bit 
random value. 

[0035] FIG. 11 shows a flow diagram of an embodi- 
ment of the forward conversion of the key conversion 
system for converting an m-bit key value KEY1 of a first 
communications system into an n-bit key value KEY2 of 
a second communications system. The m bit KEY1 is 



provided to a random function f (block 200) which maps 
an m-bit string into an n-m bit random number or first 
intermediate value R. In the example of roaming from 
the 3G communications system to the 2G TDMA com- 

5 munications system, the conversion system converts a 
128 bit key CK into a 584 bit key (VPMASK, SMEKEY). 
The 128 bit key CK is provided to the random function f 
(200) which maps the 12B bit CK into a 456 bit random 
number or first intermediate value R. The intermediate 

'0 value R is provided to a random function h (block 210) 
which maps an n-m bit string into an m bit random 
number. The m-bit output of the function h (21 0) is sub- 
ject to an exclusive-or (XOR 220) with the m bit KEY1 
to produce an m-bit second intermediate value T. In the 

'5 example of roaming from the 3G communications sys- 
tem to the 2G TDMA communications system, the 456 
bit intermediate value R is provided to the function h 
(210). The function h (21 0) maps the 456 bit value R to 
a 128 bit random number which is XORed with the 128 

20 bit CK to produce a 1 28 bit second intermediate value T. 
[0036] In the embodiment of FIG. 11, the m-bit inter- 
mediate value T is provided to a random function g 
(block 230). The random function g (block 230) maps 
an m bit string to an n-m bit random number which is 

25 subject to an exclusive-or (XOR 240) with the n-m bit 
intermediate value R to produce an n-m bit key value V 
which can be used as a key keys or portion(s) of key 
(s). In this embodiment, the value V is a portion of the 
value KEY2 which can be used as a key, keys or portion 

so (s) of key(s). In this embodiment, the n bit key KEY2 
includes the n-m bit value V along with the m bit second 
intermediate value T In the example of roaming from 
the 3G communications system to the 2G TDMA com- 
munications system, the random function g (230) maps 

35 the 128 bit intermediate value T into a 456 bit random 
number which is subject to the exclusive-or (XOR 240) 
with the 456 bit intermediate value Tto produce the 456 
bit key value V. The 456 bit value V and the 128 bit in- 
termediate value T form the 584 bit key value KEY2 

40 which in this example can be divided into the VPMASK 
and the SMEKEY for 2G TDMA systems. 
[0037] The forward conversion of the CK of the 3G 
system to the VPMASK and SMEKEY of the 2G TDMA 
system can be written according to the following steps. 

45 

1. R = f(CK) I* create a 456 bit value from 
128 bit CK by applying f 7 

2, T=h(R)XORCK r create a 128 bit val- 
ue using h 7 

so 3. V = g(T)XORR /* create a 456 bit val- 
ue using g 7 

4. Output T.V /*outputthe584bitvalue7 

[0038] FIG. 12 shows a flow diagram of an embodi- 
es ment of the reverse conversion of the key conversion 
system for converting the n-bit key value KEY2 of the 
second communications system back into the m-bit key 
value KEY1 of the first communications system. In this 
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embodiment: the n bit key value KEY2 is divided into an 
n-m bit first portion or value V and an m-bit second por- 
tion or value T. The m-bit value T is provided to the ran- 
dom function g (block 250) which maps an m-bit string 
into an n-m bit random number. The n-m bit random 
number is subjected to an exclusive-or (XOR 260) with 
the n-m bit key value V to produce the n-m bit first inter- 
mediate value R, In the example where the wireless unit 
roams back to the 2G TDMA system from the 3G sys- 
tem, the conversion system converts the 584 bit key 
(VPMASK, SMEKEY) into a 128 bit key CK. The 128 bit 
key value portion T is provided to the random function 
g (250) which maps the 1 28 bit T into a 456 bit random 
number. The 456 bit random number exclusive-ORed 
(XOR 260) with the 456 bit key value V to produce the 
456 bit first intermediate value R. 
[0039] In the embodiment of FIG. 12, the n-m bit first 
ntermediate value R is provided to a random function h 
(block 270). The random function h (block 270) maps 
an n-m bit string to an m bit random number which is 
subject to an exclusive-or (XOR 280) with the m bit key 
value T to produce an m bit key value KEY1 which can 
be used as a key, keys or portion(s) of key(s). In the 
example where the wireless unit roams back to the 2G 
TDMA system from the3G system, the random function 
h (270) maps the 456 bit intermediate value R into a 1 28 
bit random number which is subject to an exclusive-or 
(XOR 280) with the 128 bit key value T to produce the 
128 bit key CK. 

[0040] The reverse conversion of the VPMASK and 
SMEKEY of the 2G TDMA system to the CK of the 3G 
system can be written according to the following steps. 

1 . Set T,V to 584 bit input /* T is 1 28 bit 
part, V is 456 bit part 7 

2. R = g(T)XORV r create 456 bit value 
R using T, V */ 

3. CK=h(R)XORT 

[0041] The random functions f, g and h can be imple- 
mented using hash functions and/or block ciphers. To 
implement the random functions f, g, and h, which can 
be referred to as random oracles, cyptographic hash 
functions, such as the functions known as known as 
SHA-1 , MD5, RIPE-MD, can be used to instantiate the 
random functions! g, h. A hash function can be typically 
characterized as a function which maps inputs of one 
length to outputs of another, and given an output, it is 
not feasible to determine the input that will map to the 
given output. Moreover, it is not feasible to find two in- 
puts which will map to the same output. In using a SHA- 
1 hash function, each call to the SHA-1 hash function 
has a 160 bit initial vector (IV) and takes a 512 bit input 
or payload which is mapped into a 160 bit output. The 
IV is setto the IV defined in the standard for SHA-1 hash 
function. The payload will contain various input argu- 
ments: SHA(Type, Count, Input, Pad) where Type is a 
byte value which defines the various functions f, g, h. 



Function f and g will call SHA multipletimes, and Count 
is a byte value which differentiates the multiple calls. In- 
put is the input argument to the functions f, g, or h. Pad 
is zeroes to fill the remaining bit positions in the 51 2 bit 
5 SHA payload. Below is an example procedure for imple- 
menting the random function f, g and h using a hash 
function routine referred to as SHA. 
SHA(type,count,input,pad) 
f(CK): SHA(1, 1, CK, pad) 
w SHA(1, 2, CK, pad) 

SHA( 1 , 3, CK, pad) mod 2 A 1 36 
h(R): SHA( 2, 1 , R, pad) mod 2 A 1 28 
g(T): SHA(3, 1,T, pad) 
SHA(3, 2,T, pad) 
'5 SHA(3, 3,T, pad)mod2 A 136 

Block ciphers, like AES, can be used to create functions 
f. g, and h 

f(CK): E CK (1); E CK (2); E CK (3); E CK (4) mod 2*72; 
h(R); E K0 (R1 XOR 5) XOR E K0 (R2 XOR 6) XOR 
20 E K0 (R3 XOR 7) XOR 
E K0 (R4 XOR 8) 

g(T): E T (9); E T (10); E T (11); E T (12) mod 2*72; 
where in f(CK). CK is used as the key in the block cipher 
and 512 bit stream is produced by encrypting 1...4 in 
25 counter mode. The last encryption is truncated from 1 28 
bit to 72 bitto get the needed 456 bits. In h(R), a public 
key K0 is used to encrypt the parts of 456 bit R and the 
resulting ciphertexts are exclusive-ored together. R1 , 
R2, and R3 are 128 bit values and R4 is the remaining 
30 72 bit value of R. padded with zeroes to complete 1 28 
bits. 

[0042] Thus, the key conversion system provides bi- 
directional, deterministic andsecu re conversion of a key 
(s) or portion(s) thereof between first and second com- 

35 munications systems. The key conversion system is se- 
cure in the forward direction in that given most of the 
output KEY2 (for example, T.V). an adversary cannot 
recover KEY1 (for example, CK). In the example with 
the 2G TDMA and 3G systems, if all of T and most V 

40 except say 64 bits are known, then parts of R can be 
recovered, but not all of R by calculating R = g(T) XOR 
V. An attempt can be made to recover some of CK by 
performing CK = h(R) XORT However, since all of R is 
not known, even a bit of information about h(R) cannot 

45 be recovered, assuming h is a random function. Hence 
no information can be recovered about CK. Similarly, if 
all of V and part of T are known, except say 64 bits of T, 
then no information about CK can be recovered. Since 
we do not know all of T, the intermediate value R cannot 

so be calculated using g(T) XOR V. Thus without the inter- 
mediate value R, no progress can bemade in recovering 
any information about CK. 

[0043] Similarly, the key conversion system is secure 
in the reverse direction in that given most of the output 
55 KEY1 (for example, CK), an adversary cannot recover 
KEY2 (for example. T, V). In the example with the 2G 
TDMA and 3G systems, if a part of CK is known, no in- 
formation about T,V can be recovered. Since we do not 
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know all of CK : the intermediate value R cannot be cal- 
culated using f(CK). Thus without the intermediate value 
R ; no progress can bs made in recovering any informa- 
tion about T,V. 

[0044] In addition to the embodiment(s) described 
above, the key conversion system according to the prin- 
ciples of the present invention can be used which omit 
and/or add input parameters and/or random functions 
or other operations and/or use variations or portions of 
the described system. For example, the key conversion 
system has been described as converting between n bit 
key of a first communication system and an m bit key of 
a second communications system using random ora- 
cles f. g and h where the random oracles f and g map 
an m bit string to a n-m bit random number and the ran- 
dom oracle h maps a n-m bit string to an m bit random 
number. However, different random functions can be 
used as well as different or additional functions which 
map x bit strings to y bit random numbers and/or map y 
bit strings to x bit random numbers where x or y can be 
equal to n-m or m. Additionally, the m bit key value for 
the first communications system can be a key, keys or 
portion(s) thereof, and the n bit key value for the second 
communications system can be a key, keys or portion 
(s) thereof. For example, the example with the 2G TDMA 
and 3G systems, the conversion is between the 1 28 bit 
CK of the 3G system and the 584 bit key value for the 
SMEKEY and VPMASK of the 2G TDMA system, but 
the conversion could be between a 256 bit key value of 
CK and IK of the 3G system and the 584 bit key value 
for the SM EKEY and VPMASK of the 2G TDMA system. 
[0045] In the example described above, a forward 
conversion is from the m bit key value of the first com- 
munications system to the n bit key value of the second 
communications system where the first communica- 
tions system corresponds to the new system and the 
second communications corresponds to the old system 
and where m<n. However, depending on the embodi- 
ment, the first communications system can be older and 
the second communications system is newer, Alterna- 
tively, the forward conversion can be the conversion of 
the smaller size key value of one communications sys- 
tem to the larger bit size key value of another commu- 
nications system, and the reverse conversion is the con- 
version of the larger bit size key value to the smaller size 
key value. Depending on the embodiment, the conver- 
sion of different, larger, smaller and/or the same size(s) 
of key value(s) between the different communications 
systems are possible. 

[0046] Furthermore, the key conversion system can 
be used to handle the intersystem handoffs described 
in the FIGs 5-10 to convert a key, keys or portion(s) 
thereof from one communications system to the key, 
keys or portion(s) thereof of another communications 
system. It should be understood that different notations, 
references and characterizations of the various values, 
nputs and architecture blocks can be used. For exam- 
ple, the functionality described for the key conversion 



system can be performed in a home authentication cent- 
er, home location register (HLR), a home MSC, a visiting 
authentication center, a visitor location register (VLR) 
and/or in a visiting MSC. Moreover, the key conversion 
5 system and portions thereof can be performed in a wire- 
less unit, a base station, base station controller, MSC, 
VLR. HLRorothersub-system ofthefirst and/orsecond 
communications system. It should be understood that 
the system and portions thereof and of the described 
'0 architecture can be implemented in or integrated with 
processing circuitry in the unit or at different locations of 
the communications system, or in application specific 
integrated circuits, software-driven processing circuitry, 
programmable logic devices, firmware, hardware or oth- 
'5 er arrangements of discrete components as would be 
understood by one of ordinary skill in the art with the 
benefit of this disclosure. What has been described is 
merely illustrative of the application of the principles of 
the present invention, Those skilled in the art will readily 
20 recognize thatthese and various other modifications, ar- 
rangements and methods can be made to the present 
invention without strictly following the exemplary appli- 
cations illustrated and described herein and without de- 
parting from the spirit and scope of the present inven- 
ts tion, 



Claims 

30 1. A method of converting a first key value (key 1) for 
a first communications system to a second key val- 
ue (key 2) of a second communications, said meth- 
od CHARACTERIZED BY: 

35 generating a first intermediate value (R) from 

at least a portion of said first key value (key 1 ) 
using a first random function (f) 
providing at least a portion of said first interme- 
diate value (R) to a second random function (h) 

40 to produce a second value; 

performing an exclusive-or (220) on at least a 
portion of said first key value (key 1) and at least 
a portion of said second value to generate a 
second intermediate value (T); 

45 providing at least a portion of said second in- 

termediate value (T) to a third random function 
(g) to produce a third value; and 
producing at least a first portion of said second 
key value (key 2) by performing an exclusive- 

so or (240) on at least a portion of said third value 

and at least a portion of said first intermediate 
value (R). 

2. The method of claim 1 CHARACTERIZED BY: 

55 

producing at least a portion of said second in- 
termediate value (T) as at least a second por- 
tion of said second key value (key 2). 
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3. The method of claim 1 CHARACTERIZED BY said 
generating comprises the step of: 

providing said first ksy value (key 1) of m bits 
to a first random function (f)to produce said first s 
intermediate value (R) of n-m bits. 

4. The method of claim 3 CHARACTERIZED IN THAT 

said first steps of providing and performing com- 
prise: 10 

providing said n-m bit first intermediate value 
(R) to a second random function (h) to produce 
an m bit second value; and 
performing an exclusive-or (220) on said m bit '5 
first key value (key 1) and said m bit second 
valueto generate said second intermediate val- 
ue (T) with m bits. 

5. The method of claim 4 CHARACTERIZED IN THAT 20 

said second step of providing and said step of pro- 
ducing comprise: 

providing said m bit second intermediate value 
(T) to a third random function (g) to produce a 2$ 
n-m bit third value; and 

performing an exclusive-or (240) on said n-m 
bit third value and said n-m bit first intermediate 
value (R) to generate an n-m bit portion (V) of 
said second key value (key 2). so 



A key conversion system for converting a first key 
value (key 1) for a first communications system to 
a second key value (key 2) of a second communi- 
cations ; said system CHARACTERIZED BY: 

processing circuitry adapted to generate a first 
intermediate value (R) from at least a portion of 
said first key value (key 1 ) using a first random 
function (f) to provide at least a portion of said 
first Intermediate value (R) to a second random 
function (h) to produce a second value, to per- 
form an exclusive-or (220) on at least a portion 
of said first key value (key 1 ) and at least a por- 
tion of said second value to generate a second 
intermediate value (T) , to provide at least a por- 
tion of said second intermediate value (T) to a 
third random function (g) to produce a third val- 
ue and to produce at least a first portion of said 
second key value (key 2) by subjecting at least 
a portion of said third value to an excluslve-or 
(240) with at least a portion of said first inter- 
mediate value (R). 

10. The system of claim 9 CHARACTERIZED IN THAT 

said processing circuitry further configured to pro- 
duce at least a portion of said second intermediate 
value (T) as at least a second portion of said second 
key value (key 2). 



6. The method of claim 5 CHARACTERIZED BY: 

providing said m bit second intermediate value 
(T) as an m bit second portion of said second 35 
key value (key 2) having n bits. 

7. The method of claim 2 CHARACTERIZED BY the 

steps of: 

40 

providing said second portion (T) of said sec- 
ond key value (key 2) to said third random func- 
tion (g) to produce said third value; and 
generating said first intermediate value (R) by 
subjecting said first portion (V) of said second 45 
key value (key 2) to an exclusive-or (260) with 
said third value. 

8. The method of claim 7 further CHARACTERIZED 
BY: so 



using said second random function (h) to gen- 
erate said second value from said first interme- 
diate value (R): and 

producing at least a portion of said first key by ss 
subjecting said second value to an exclusive- 
or (280) with said second portion (T) of said 
second key value (key 2). 
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Description 

TECHNICAL FIELD 

[0001] The present invention relates to a techniquefor 
distributing a program (application or applet) to a stor- 
age module built or mounted in a mobile terminal. 

BACKGROUND ART 

[0002] In recent years, a mobileterminal has been de- 
veloped which has a program executing environment. 
An example of a mobileterminal of this type is one which 
has a Java virtual machine. The user installs a program 
in the mobile terminal and thus can add a desired func- 
tion to the mobile terminal. 

[0003] However, even if desirablefunctions are added 
to a mobile terminal, a user is liable to become tired of 
using the same mobile terminal after a protracted peri- 
od. On the other hand, the mobile terminal industry suf- 
fers fierce competition and various new products, attrac- 
tive to users, have been successively placed on the mar- 
ket. A user may want to change his mobile terminal with 
a new desirable product placed on the market. Once the 
mobileterminal is replaced, however, the functions that 
have hitherto been added to the old mobileterminal can- 
not be used any longer. If the same functions are to be 
used even after the change of a mobileterminal, the pro- 
gramsthat have been installed in the old mobileterminal 
have to be installed in the new mobile terminal. This is 
a troublesome job. 

DISCLOSURE OF THE INVENTION 

[0004] This invention has been achieved in view of the 
situation described above, and the object thereof is to 
provide a system in which even after a mobile terminal 
is changed, the programs that could be used before the 
change of the mobileterminal, can be continuously used 
after the change. 

[0005] In order to achieve this object, the present in- 
ventors have taken notice of a certain type of a mobile 
terminal, that is to say, a mobile terminal capable of be- 
ng mounted or having fitted therein amoduleforstoring 
the subscriber information including the subscriber 
number and the memory dial information (hereinafter re- 
ferred to as the user ID module or UIM) The user of this 
type of the mobile terminal, whenever desirous of 
changing it with a new mobile terminal, can use the new 
mobileterminal in similar manner simply by mounting or 
building into the new mobile terminal the UIM which he 
may have. In connection with this, the present inventors 
have come up with the following idea. Specifically, once 
a program is stored in this UIM, the program used with 
the old mobile terminal can be easily transferred to the 
new mobile terminal for an improved operating conven- 
ience of the user. 

[0006] Nevertheless, the problem of security has 



been an obstacle to realizing such a novel mobile ter- 
minal. 

[0007] First, as long as no limit is set on the operation 
of writing a program in the UIM, the inherent functions 
5 of the mobileterminal may be undesirably destroyed in- 
tentionally or negligently. 

[0008] Also, the subscriber information stored in the 
UIM may include the personal information or data hav- 
ing monetary value. From the viewpoint of security, 
'0 therefore, careful consideration is necessary not to 
cause the leakage of this information in writing a pro- 
gram in the UIM. 

[0009] In order to solve this security problem and im- 
prove the operating convenience for the user, according 

'5 to the present invention, there is provided a program dis- 
tribution system comprising a mobile terminal having 
means for transmitting a program distribution request, 
a storage module built in or connected to the mobile ter- 
minal, a contents serverfor receiving the distribution re- 

20 quest and transmitting a program to be distributed, and 
a distribution management server for receiving the pro- 
gram from the contents server and. as long as the con- 
tents server is authorized, transmitting the program re- 
ceived from the contents server to the storage module 

25 built in or connected to the mobile terminal, character- 
ized in that the storage module includes a storage unit, 
and a control unit for storing in the storage unitthe pro- 
gram received from the distribution management server 
through the mobile terminal and executing the program 

30 stored in the storage unit in response to a request. 
[0010] Also, according to the present invention, there 
is provided a program distribution system comprising a 
mobile terminal having means for transmitting a pro- 
gram distribution request, a storage module built in or 

35 connected to the mobile terminal, and a distribution 
management server for receiving the distribution re- 
quest; and in the case where the program to be distrib- 
uted is provided by the authorized contents server, ac- 
quiring and transmitting the program to the storage mod- 

40 ule built in or connected to the mobile terminal, charac- 
terized in that the storage module includes a storage 
unit, and a control unit for receiving the information 
through the mobile terminal, storing the information in 
the storage unit only in the case where the information 

45 is the program received from the distribution manage- 
ment server and executing the program stored in the 
storage unit in response to a request. 
[0011] With these systems, only a program supplied 
through the distribution management server from an au- 

50 thorized contents server is written in the storage module 
and therefore, the user can write a new program in the 
storage module with guaranteed security. 

BRIEF DESCRIPTION OF THE DRAWINGS 

55 

[0012] 

Fig. 1 is a block diagram showing a configuration of 
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a program distribution system according to a first 
embodiment of the invention. 
Fig. 2 shows the external appearance of a mobile 
terminal according to the same embodiment. 
Fig. 3 is a block diagram showing a configuration of 
the same mobile terminal, 
Fig. 4 is a diagram showing a configuration of the 
same mobile terminal and the UIM built in or con- 
nected to it. 

Fig. 5 is a sequence diagram showing the process 
from program distribution to activation according to 
the same embodiment. 

Fig. 6 is a sequence diagram showing the program 
distribution operation according to the same em- 
bodiment. 

Fig. 7 is a diagram showing a display screen of the 
mobile terminal at the time of program distribution. 
Fig. 8 is a sequence diagram showing the program 
activation operation according to the same embod- 
iment. 

Fig. 9 is a sequence diagram showing the process- 
es of the program deactivation in compliance with 
a request from the contents server according to the 
same embodiment. 

Fig. 10 is a sequence diagram showing the process 
of the program delete operation in compliance with 
a request from the contents server according to the 
same embodiment. 

Fig. 11 is a sequence diagram showing the process 
of the program deactivate operation and the pro- 
gram delete operation in compliance with a request 
from the distribution management server according 
to the same embodiment, 
Fig. 12 is a sequence diagram of the UIM exchang- 
ing the version information according to the same 
embodiment. 

Fig. 13 is asequence diagram showing the process 
ending in a program distribution failure due to a 
memory shortage. 

Fig. His asequence diagram showing the process 
ending in a program distribution failure due to a 
memory error. 

Fig. 1 5 is a diagram showing a display screen pro- 
vided to the user at the time of program deletion 
Fig. 1 6 is a diagram showing a display screen pro- 
vided to the user at the time of account settlement 
for an electronic commercial transaction. 
Fig. 1 7 is a diagram showing a display screen pro- 
vided to the user at the time of commodity purchase 
in male order sale. 

Fig. 18 is a diagram showing a display screen for 
setting the automatic program start. 
Figs. 19 and 20 are diagrams showing a display 
screen at the time of using a commutation pass. 
Fig. 21 is a block diagram showing a configuration 
of a program distribution system according to a sec- 
ond embodiment of the invention. 
Fig. 22 is a diagram showing a configuration of a 



memory in the UIM according to the same embod- 
iment. 

Fig. 23 is a block diagram showing a configuration 
of a distribution management server 1 6A according 

5 to the same embodiment. 

Fig. 24 is asequence diagram showing the process 
for registration in a user information storage unit. 
Figs. 25 and 26 are sequence diagrams showing 
the operation of registering a program registered in 

'0 the user information storage unit, in any of the basic 
blocks of the UIM 12. 

Figs. 27 and 28 are sequence diagrams showing 
the operation of registering a program registered in 
the user information storage unit, in any of the basic 
'5 blocks of the UIM 

Fig. 29 is a sequence diagram showing the opera- 
tion of deleting a program registered in the user in- 
formation storage unit 51 . 

Fig. 30 is a sequence diagram showing the opera- 
te tion of deleting a program registered in the basic 
blocks of the UIM 

Fig. 31 is a sequence diagram showing the deacti- 
vation process forthe user information storage unit. 
Fig. 32 is a sequence diagram showing the deacti- 
25 vation process for the basic blocks. 

BEST MODE FOR CARRYING OUT THE INVENTION 

[0013] Now : preferred embodiments of the invention 
30 will be explained with reference to the drawings, 

[1] First embodiment 

[1.1] General configuration of program distribution 
35 system 

[001 4] Fig. 1 is a block diagram showing a configura- 
tion of a program distribution system according to a first 
embodiment of the invention. 

40 [0015] Aprogram distribution system 10 roughly com- 
prises a mobile terminal 11 , a radio base station 13, a 
switching station 14, a network mobile communication 
service control unit 15 : a distribution management serv- 
er 1 6 : a distribution service control unit 1 7, an authenti- 

45 cation server 1 8, a contents server 1 9 and a public net- 
work 20. 

[0016] The mobile terminal 11 is an information 
processing unit, for example, having communication 
functions such as a portable telephone or a PHS (Per- 

50 sonal Handyphone System (registered trade name)). 
Further, the mobile terminal 11 has mounted or built 
therein a UIM (User Identification Module) 12 capable 
of storing various programs or data. 
[0017] The radio base station 13 communicates with 

55 the mobile terminal 11 through a radio link. 

[0018] The switching station 14 controls the switching 
operation between the mobile terminal 11 and a com- 
mon channel interoffice signal network 20 constituting a 
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wire network, connected to each otherthrough the radio 
base station 13. 

[0019] The network mobile communication service 
control unit 15 controls the communication in the case 
where a program is distributed to the mobile terminal 1 1 
through the public network 20. 
[0020] The contents server 1 9 distributes various con- 
tents on the one hand and distributes a program as re- 
quested from the mobile terminal 11 on the other, 
[0021] The distribution management server 1 6 relays 
and manages the distribution of a program from the con- 
tents server 19 to the UIM 12. The distribution of a pro- 
gram to the UIM 12 and access to a program stored in 
the UIM 12 are carried out always through the distribu- 
tion management server 1 6. This is the most significant 
feature of this embodiment. 

[0022] The distribution service control unit 17 oper- 
ates like an interface between the distribution manage- 
ment server 16 and the public network 20 in the case 
where a program is distributed through the public net- 
work 20. 

[0023] The authentication server 1 8 is a device for is- 
suing a certificate required for program distribution to 
the contents server 19. This certificate includes a UIM 
public key having the function of explaining, forthe ben- 
efit of the UIM 12, that the contents server 19 is duly 
authorized to distribute a program to the UIM 12, and a 
distribution management server public key having the 
function of certifying, for the benefit of the distribution 
management server 16. that the contents server 19 is 
similarly authorized. 

[0024] The contents server 19, the distribution man- 
agement server 1 6 and the authentication server 1 8 ac- 
cordingtothis embodiment have thefollowingfunctions. 
respectively. 

(a) According to this embodiment, the contents 
server 19 sends a program addressed to the UIM 
1 2, to the distribution management server 16, which 
in turn distributes the program to the UIM 12. The 
contents server 1 9 never distributes the program di- 
rectly to the UIM 12. 

(b) The contents server 1 9 distributes a program to 
the UIM 1 2 by encrypted communication of a public- 
key type with the distribution management server 
16 as an intermediary. The UIM 12 of each user is 
equipped with a PKI (public key infrastructure), and 
each UIM 12 has a UIM private key unique to the 
particular UIM 12. For distributing a program ad- 
dressed to a given UIM 12, the contents server 19 
acquires a UIM public key paired with a UIM private 
key forthe particular UIM 12, whereby the program 
is encrypted 

(c) According to this invention, only an authorized 
contents server 19 can distribute a program ad- 
dressed to the UIM 12. The authorized contents 
server 19 is assigned a distribution management 
server public key. The contents server 19, upon re- 



ceipt of a distribution request from the mobile ter- 
minal 1 1 , further encrypts, by the distribution man- 
agement server public key, the program already en- 
crypted by the UIM public key and addressed to the 
5 UIM 12, and sends it to the distribution manage- 
ment server 1 6. 

[1 .2] Configuration of mobile terminal 

w [0025] Fig. 2 shows the external appearance of the 
mobile terminal 11. The mobile terminal 11 includes a 
display section 21 and an operating section 22. 
[0026] As shown in Fig. 2, various processing menu 
items, the screen being browsed, the telephone number 

'5 screen, etc. are displayed on the display section 21 . 
[0027] The operating section 22 has a plurality of op- 
erating buttons for inputting various data and displaying 
menu item screens. One of the operating buttons of the 
operating unit 22 is a UIM button 23, The UIM button 23 

20 is operated by the user for utilizing a program stored in 
the UIM 12. 

[002B] Fig. 3 is a block diagram showing a configura- 
tion of a mobile terminal. 

[0029] The mobile terminal 11 includes a display sec- 

25 tion 21 , an operating section 22, a control unit 31 , a stor- 
age unit 32, an external equipment interface (l/F) unit 
33. a communication unit 34, a UIM interface (l/F) unit 
35 and an voice input/output unit 36. 
[0030] The control unit 31 controls the various parts 

30 of the mobile terminal 11 based on the control data and 
the control program stored in the storage unit 32. 
[0031] The storage unit 32 is configured of a ROM, a 
RAM, etc., and has a plurality of storage areas including 
a program storage area for storing various programs 

35 such as a browser for accessing an internet and a data 
storage area for storing various data. 
[0032] The external equipment l/F unit 33 is an inter- 
face utilized by the control unit 31 and the UIM 12 for 
exchanging information with an external device. 

40 [0033] The communication unit 34 transmits various 
data including audio and text messages to the radio 
base station 1 3 through the antenna 34A under the con- 
trol of the control unit 31 on the one hand, and receives 
various data sent to the mobile terminal 11 through the 

45 antenna 34A on the other hand. 

[0034] The UIM l/F unit 35 inputs/outputs data from 
and to the control unit 31 . The UIM l/F unit 35 also out- 
puts the output data from the communication unit 34 or 
the external equipment l/F unit 33 to the UIM 12 without 

so the intermediation of the control unit 31 . Also, the output 
data of the UIM 12 is output directly to the external 
equipment l/F unit 33 or the communication unit 34 di- 
rectly without the intermediation of the control unit 31 . 
The reason why the data are input/output from and to 

55 the external equipment l/F 33 orthe communication unit 
34 without the intermediation of the control unit 31 , is in 
orderto prevent an illegal access to the data on the UIM 
12 by the alteration of the control program of the control 
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unit 31 and thus to maintain security. 
[1.3] Configuration of UIM 

[0035] Fig. 4 shows a configuration of the UIM 12. In 
Fig. 4, a part of the component elements of the mobile 
terminal 11 are shown together with the component el- 
ements of the UIM 12 to clarify the relation with the mo- 
bile terminal 11 . As shown in Fig, 4, the UIM 12 includes 
a memory 1 2M, which in turn, roughly, has a system ar- 
ea 12A and an application arsa 12B. 
[0036] ThG system area 12A has stored therein per- 
sonal information data unique to each user such as sub- 
scriber number data, outgoing call history information 
data, incoming call history information data, speech time 
nformation data and a UIM private key. The mobile ter- 
minal 11 communicates with other communication units 
using the subscriber number data in the system area 
12A as a calling line identity. 

[0037] The application area 12B is forstoring the pro- 
gram distributed and the data used at the time of exe- 
cution of the program, and divided into a plurality of ba- 
sic blocks. In the case shown in Fig. 4. the application 
area 12B is divided into six basic blocks 40-1 to 40-6 
[0038] The basic blocks 40-1 to 40-6 each include a 
program area 41 and a data area 42. The program area 

41 of eachbasicblock40-khasstoredtherein aprogram 
(an application or an applet). The data area 42 of each 
basic block 40-k, on the other hand, has stored therein 
the data used at the time of executing the program in 
the program area 41 of the same basic block 40-k. 
[0039] The basic blocks 40-1 to 40-6 are independent 
of each other, and are basically so managed that the 
application or the applet stored in the program area 41 
of a given basic block 40-j cannot access the data area 

42 of another basic block 40-k (# j). By employing this 
configuration, the security of each program is main- 
tained. Even in the case where data having a monetary 
value (what is called "a value") are recorded in the data 
area 42 of a given basic block 40-j, therefore, the par- 
ticular data is never rewritten, intentionally or incidental- 
ly, by a program stored in another basic block 40-k j). 
[0040] The application orthe applet constituting a pro- 
gram stored in the program area 41 , on the other hand, 
cannot be distributed or deleted without the intermediary 
of the distribution management server 1 6. The data area 
42, however, can be operated directly through the dis- 
tribution management server 16 or a local terminal as 
in the case where the electronic money is downloaded 
from an ATM. 

[0041] Further, the application area 1 2 has a storage 
area for an activation flag indicating whether the pro- 
gram in the program area 41 of each of the basic blocks 
40-1 to 40-6 can be executed or not. 
[0042] The control unit 30 is a means for writing a pro- 
gram forthe basic block of the application area 12B, set- 
ting or resetting the activation flag corresponding to 
each basic block or executing a program in a designated 



basic block, in response to a request given through the 
mobile terminal 11. Upon arrival of a program encrypted 
by the UIM public key from the distribution management 
server 1 6, the control unit 30 decrypts the program using 

5 the UIM private key in the system area 12 and writes it 
in a basic block. Also, the control unit 30 can execute 
the program in the basic block. In the process, the infor- 
mation required by the program in execution is acquired 
from the other party of the communication in the network 

'0 or from the user of the mobile terminal 1 1 through the 
browser executed by the mobile terminal 1 1 . The control 
unit 30 can also send the result of program execution to 
the other party of communication in the network or send 
it to the user of the mobile terminal 11 through the brows- 

'5 er. Also, the control unit 30 can exchange information 
with external devices through the hardware resources 
of the mobile terminal 11 without the intermediary of the 
browser in accordance with the program in the basic 
block. An example of a program available for this pur- 

20 pose is an application program for causing the mobile 
terminal 11 to function as a commutation pass. In exe- 
cuting this program, the control unit 30 can exchange 
the pass information with the card reader/writer at the 
gates of a railway station utilizing a short-range radio 

25 unit (not shown) connected to the external equipment I/ 
F of the mobile terminal 30. The program forthe control 
unit 30 to perform the various processes described 
above, including the execution and control of the pro- 
gram in the application area is stored in thesystem area 

30 12A. 

[1 .4] Operation of first embodiment 

[0043] Now. the operation of the first embodiment will 
35 be explained taking the distribution of the commutation 
pass applet as an example. 

[0044] Fig. 5 isasequencediagramshowingtheproc- 
ess of program distribution, write operation and activa- 
tion. 

40 [0045] As shown in Fig. 5, these series of processes 
are roughly configured of the step of distributing an in- 
active program (applet) as a memory module tothe UIM 
12 and writing it in the UIM 12 (step S1), and an activa- 
tion step for activating the program written (step S2). 

45 

[1.4,1] Issue of certificate to distribution management 
server 

[0046] Fig. 6 is asequence diagram showing the proc- 
so ess of distributing a program and writing it in the UIM 
12. As shown in Fig. 6, the authentication server 18 is- 
sues a certificate to the contents server 1 9 permitted to 
distribute the program addressed to the UIM 12 (step 
S11). The certificate is issued to enable the contents 
55 server 1 9 and the distribution management server 1 6 to 
perform the encryption communication based on the 
public key encryption method. Specifically in order to 
make possible the encryption communication using a 
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public key, a distribution management serverprivate key 
and a distribution management server public key, con- 
stituting a pair, are generated. The distribution manage- 
ment serverprivate key is stored in the distribution man- 
agement server 16. while the distribution management 
server public key is transmitted from the authentication 
server 18 to the contents server 19 as a certificate iden- 
tifying a person permitted to distribute a program. The 
contents server 1 9, upon receipt of the distribution man- 
agement server public key, stores it in preparation for 
program distribution. 

[1.4.2] Program distribution request 

[0047] The user can cause the control unit 31 to exe- 
cute the browser and thus can access the home page 
of the contents provider by operating the operating sec- 
tion 22 of the mobile terminal 1 1 . As a result of this ac- 
cess, a distribution menu screen D1 indicating the pro- 
gram distribution performed by the contents server 19 
of the contents provider is displayed, as shown in Fig. 
7, on the display section 21 of the mobile terminal 11. 
Under this condition, the usertransmits a program (ap- 
plet) distribution request from the mobile terminal 11 
through the network to the contents server 1 9 by oper- 
ating the operating section 22 of the mobile terminal 11 
(step S12). 

[1 .4.3] Certificate issue request to UIM 

[0048] The contents server 1 9, upon receipt of a dis- 
tribution request from the mobile terminal 11 , sends a 
certificate issue request to the authentication server 18 
(step S12). This certificate issue request contains the 
nformation for specifying the UIM 12 of the mobile ter- 
minal 11. The certificate issue is requested in order to 
enable the contents server 1 9 to conduct the encryption 
communication of public key type with the UIM 12. More 
specifically, in order to make possible the encryption 
communication of public key type, the UIM private key 
and the UIM public key paired with the former are gen- 
erated in advance, and the UIM private key is stored in 
the UIM 12 in advance, while the UIM public key is 
stored in the authentication server 18 in advance. In step 
S12, the UIM public key stored in the authentication 
server 18 is requested as a certificate of a person per- 
mitted to distribute a program addressed to the UIM 12. 

[1 .4.4] Issue of certificate and distribution of program 
with certificate to UIM 

[0049] The authentication server 18, upon receipt of 
a certificate issue request from the contents server 1 9, 
issues to the contents server 19 a UIM public key as a 
certificate corresponding to the UIM 12 specified by the 
particular issue request (step S14). 
[0050] The contents server 1 9 encrypts the program 
of which distribution is requested, by useoftheUlM pub- 



lic key corresponding to the UIM 12. The program ob- 
tained by the encryption is considered a program with a 
certificate for a legitimate person authorized to access 
the UIM 12. 

5 [0051] Then,theprogramencryptedbytheUIMpublic 
key is further encrypted by the contents server 1 9 using 
the distribution management server public key received 
from the authentication server 18 in advance. The pro- 
gram obtained by this encryption can be considered a 

w program having attached thereto both a certificate 
showing a legitimate person authorized to access the 
UIM 12 and a certificate showing a legitimate person au- 
thorized to distribute a program through the distribution 
management server 1 6. 

15 

[1.4,5] Program distribution 

[0052] The contents server 1 9 distributes the program 
obtained by the aforementioned two encryption ses- 
20 sions, to the distribution management server 1 6 through 
the network (step S15). 

[0053] The distribution management server 16 de- 
crypts the encrypted program distributed from the con- 
tents server 19, using the distribution management 

25 server private key. Once this decryption succeeds, the 
program encrypted only by the UIM public key can be 
obtained, In this case, the contents server 19 can be 
considered a legitimate person authorized to distribute 
a program addressed to the UIM 12. The distribution 

30 management server 1 6 transmits the data on the screen 
D2 shown in Fig. 7 to the mobile terminal 11 , and causes 
the data to be displayed on the display section 21 . This 
screen D2 is for making an inquiry at the user as to 
whether the program can be distributed or not. 

35 

[1.4,6] Writing in UIM 

[0054] After the user confirms the screen D2 and per- 
forms the operation through the operating section 22 for 

40 permitting the program distribution, a notice to permit 
distribution is sent to the distribution management serv- 
er 16. The distribution management server 16, upon re- 
ceipt of the notice, distributes to the UIM 1 2 the program 
obtained by decryption, i.e. the program encrypted by 

45 the UIM public key (step S16). 

[0055] This encrypted program is delivered as it is to 
the control unit 30 of the UIM 12 through the mobile ter- 
minal 1 1 , Specifically, the mobile terminal 1 1 simply pro- 
vides the UIM 1 2 with the communication function. This 

so operation by the mobile terminal 1 1 guarantees the se- 
cure transmission to and thesecure write operation into 
the UIM 12. 

[0056] If the distribution management server 16 is to 
send a program to the UIM 12 in the aforementioned 
55 manner, it is necessary forthe distribution management 
server 16 to establish a link with the UIM 12, This in turn 
requires the acquisition of the telephone number of the 
mobile terminal 11 with the UIM 12 connected thereto 
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or built therein. 

[0057] In one conceivable method to achieve this, at 
the time of issuing a distribution request from the mobile 
terminal 11 to the contents server 19, the telephone 
number of the mobile terminal 11 is caused to be trans- 
mitted to the contents server 1 9 which sends this tele- 
phone number to the distribution management server 
16. In this way, the distribution management server 16 
can access the mobile terminal 1 1 using the telephone 
number sent to it, and thus can distribute the program 
addressed to the DIM 12. 

[0058] Another available method is described below. 
Specifically, in advance of issuing a distribution request 
from the mobile terminal 11 to the contents server 19, 
an identifier is determined between the mobile terminal 
11 and the distribution management server 16 in place 
of the telephone number of the mobile terminal 11 , so 
that the distribution management server 16 stores the 
telephone number and the identifier as Information cor- 
responding to each other. The mobile terminal 11 sends 
a distribution request containing the identifiertothecon- 
tents server 1 9, which in turn attaches the identifier to a 
program when sending the program to the distribution 
management server 16. The distribution management 
server 1 6 determines the telephone number of the mo- 
bile terminal 1 1 from the identifier, and based on this tel- 
ephone number, calls the mobile terminal 1 1 and distrib- 
utes the program addressed tothe UIM 12. This method 
has the advantage that the need is eliminated of notify- 
ing the telephone number of the mobile terminal 11 to 
the contents server 19. 

[0059] The control unit 30 of the UIM 1 2, upon receipt 
of a program encrypted by the UIM public key in the 
manner described above, decryptsthe program using a 
UIM private key paired with the particular UIM public 
key. Once this decryption ends in success, a program 
is obtained in the form of an ordinary text not encrypted. 
In this case, the contents server 19 making up the origin 
is considered a person duly authorized to distribute a 
program to the UIM 12. The UIM 12 writes the program 
obtained by decryption, in the appropriate one of the ba- 
sic blocks 40-1 to 40-6 of the memory, 
[0060] During this write operation, the screen D3 
shown in Fig. 7 is displayed by the mobile terminal 11 

[1 .4.7] Write completion response 

[0061] At the end of the program write operation, the 
control unit 30 oftheUlM 12 transmits a write completion 
notice to the distribution management server 1 6 togeth- 
er with the information specifying the basic block having 
the particular program written therein (step S17). 
[0062] In the process, the screen D4 indicating that 
the write operation is complete (the registration is over) 
is displayed, as shown in Fig. 7, on the display section 
21 of the mobile terminal 11 . After that, the screen is 
again turned to D1 by the user operation. 



[1.4,8] Distribution completion notice 

[0063] The distribution management server, upon re- 
ceipt of a program write completion notice from the UIM 

5 12, registers the information specifying the written pro- 
gram in a data base as information corresponding to the 
information indicating the basic block of the UIM 12 in 
which the particular program is written. 
[0064] By accessing to the data base, the distribution 

'0 management server 16 can easily grasp the program 
stored in each of all the basic blocks 40-1 to 40-6 of the 
UIM 12. 

[0065] The distribution management server 1 6, upon 
distribution of a program into the UIM 12, starts the 

'5 charge process against the contents provider of the con- 
tents server 19 from which the program is distributed. 
The timing of starting the charge process is not limited 
to this, but may be coincident with the timing of activation 
described later, 

20 [0066] The contents provider are charged against the 
following items. 

(a) Rental charge for basic blocks in UIM 12 

25 [0067] Upon distribution of a program from the con- 
tents server 1 9 to the UIM 12, the particular program is 
stored in one of the basic blocks 40-1 to 40-6 in the UIM 
12. The particular basic block can be considered to be 
rented to the contents provider owning the contents 

30 server 19 for storing the program. Thus, a charge cor- 
responding to the rental period, i.e. the period during 
which the program is stored in the basic block is made 
against the contents provider as a rental charge, 

35 (b) Transaction fee 

[0068] The program transmitted from the contents 
server 19 is distributed to the UIM 12 through the proc- 
ess in the distribution management server 1 6. A consid- 

40 eration for the process performed by the distribution 
management server 1 6 is charged against the contents 
provider as a transaction fee. 
[0069] The user of the UIM 12 receives the service in 
terms of the distribution of a program from the contents 

45 server 19, and therefore is required to pay the charge 
in consideration of the service. The distribution manage- 
ment server 1 6 may collect the service charge from the 
user on behalf of the contents provider together with the 
communication charge forthe user, and delivers the col- 

50 lected service charge to the contents provider in the 
character of what might be called a "factor". In this case, 
the charge made against the contents provider may con- 
tain the factoring fee. 

[0070] Upon complete program distribution, the distri- 
55 bution management server 16 notifies the contents 
server 19 (step S18). 
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[1 .4,9] Activation 

[0071] The program distributed to the UIM 12 and 
stored in the basic block cannot be executed by the user 
before activation. 

[0072] The user only receives the distribution but is 
not permitted to execute the program distributed to him. 
in order to enable the contents provider to control the 
program execution start time, 

[0073] The activation is effectively utilized, for exam- 
ple, in the case where the time to start the use of a newly 
marketed game program is determined. By use of the 
activation, the release date (program distribution date) 
and the date to start to use (activation date) can be set 
separately from each other thereby making it possible 
to reduce the load on the contents server 19. 
[0074] Another example is a case in which the pro- 
gram for using the mobile terminal 11 as a commutation 
pass is distributed to the UIM 12. In this case, the acti- 
vation is utilized to make the program executable from 
the first date of the term of validity of the commutation 
pass. 

[0075] The operation for activation will be explained 
below with reference to Fig, 8. 

[1 .4,9.1] Activation requestto distribution management 
server 

[0076] Whenever the activation becomes necessary 
for a given program, the contents server 19 sends an 
activation request to the distribution management serv- 
er 16 (step S21). This activation request contains the 
nformation specifying a program to be activated. Also, 
in the case where only the program stored in the UIM 
12 of a specific user is activated, the activation request 
contains the identifier (the telephone number of the mo- 
bile terminal 11 or an alternative identifier) of the partic- 
ular user, 

[1 .4,9.2] Activation request to UIM 

[0077] The distribution management server 16. upon 
receipt of an activation request, issues an activation re- 
questto the UIM 12 of the mobile terminal 11 (stepS22). 
As already described, the information specifying the 
written program is registered in the data base of the dis- 
tribution management server 16 as information corre- 
sponding to the information indicating the basic block of 
the UIM 12 in which the program is written. The distri- 
bution management server 16, upon receipt of the acti- 
vation request, refers to the particular data base and de- 
termines the UIM 1 2 to which the program to be activat- 
ed is distributed and the basic block in which the pro- 
gram is written. In the case where the same program 
stored in a plurality of UIMs 12 is activated, as many 
activation processes as the UIMs 12 are performed. 
Each mobile terminal 11 in which thecorresponding UIM 
12 is mounted or built is accessed, and an activation 



request is sent to the UIM 12. The activation request 
sent to each mobile terminal 1 1 contains the information 
specifying the basic block having stored therein the pro- 
gram to be activated. 

5 [0078] This activation request, when received by the 
mobile terminal 11, is directly sent to the UIM 12. The 
control unit 30 of the UIM 12 executes the activation in 
accordance with the activation request. Specifically the 
UIM 12 sets the activation flag from "0" to "1" for the 

'0 basic block specified by the activation request. The con- 
trol unit 30 of the UIM 12 responds to a request, if any, 
to execute the program stored in the basic block with 
the activation flag turned "1", A request, if any, to exe- 
cute the program in the basic block with the activation 

'5 flag "0", however is rejected. 

[1.4,9.3] Activation end response 

[0079] The UIM 12, upon complete program activa- 
te tion , transmits an activation end notice to the distribution 
management server 1 6 (step S23). This notice contains 
the information specifying the program of which the ac- 
tivation is ended, or more specifically, the information 
specifying the basic block storing the particular pro- 
25 gram. 

[1.4,9.4] Activation completion notice 

[0080] The distribution management server 1 6, upon 

30 receipt of the activation completion notice from the UIM 
12, determines the basic block of the UIM 12 in which 
the completely activated program is stored. The infor- 
mation to the effect that the activation is completed is 
registered in the storage area in the data base prepared 

35 for the particular basic block. 

[0081 ] As the result of this registration, the distribution 
management server 1 6 can grasp, by accessing the da- 
ta base, whether each program in the basic blocks 40-1 
to 40-6 is activated or not for all the UIMs 12. 

40 [0082] Upon registration of activation completion for 
all the UIMs to which the program of which the activation 
is requested are distributed, the distribution manage- 
ment server 1 6 notifies the contents server 1 9 that the 
program activation is complete (step S24). This notice 

45 contains the information specifying the program that has 
been activated. 

[1.4,10] Deactivation 

so [0083] The program distributed to the UIM 12 and ac- 
tivated may require deactivation. This requirement oc- 
curs, for example, in a case where a program for the 
mobile terminal 11 to function as a credit card is stored 
in the UIM 12, and the user has lost the particular UIM 

55 12. In such a case, the deactivation is started in re- 
sponse to the request from the user informed of the loss. 
Other examples include a case in which the user that 
has received a service has failed to pay the service 
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charge before the due date. In such a case, at the re- 
quest of the contents provider providing such a service, 
the deactivation of the program for receiving the partic- 
ular service can be started. 

[0084] The deactivation process will be explained be- 
low with reference to Fig. 9, 

[1.4,10.1] Deactivation request to distribution 
management server 

[0085] The contents server 1 9. whenever required to 
deactivate a program distributed to a UIM 12, sends a 
deactivation request to the distribution management 
server 16 specifying the particular UIM 12 and the pro- 
gram to be deactivated (step S31 ). 

[1.4,10.2] Deactivation request to UIM 

[0086] The distribution management server 16. upon 
receipt of this deactivation request, accesses the data 
base and determines that basic block in the UIM 12 
specified by the deactivation request which stores the 
program to be deactivated. Then, the distribution man- 
agement server 1 6 sends a deactivation request to the 
mobile terminal 11 in which the particular UIM 12 is 
mounted or built (step S32). This deactivation request 
contains the information specifying the basic block stor- 
ng the program to be deactivated. 
[0087] The deactivation request is sent to the UIM 12 
through the mobile terminal 1 1 . The activation flag pre- 
pared for the basic block specified by the deactivation 
request is reset from "1 " to "0" by the UIM 12. After that, 
the execution of the program in this particular basic 
block is prohibited. 

[1.4.10.3] Deactivation end response 

[0088] The UIM 12. upon termination of the program 
deactivation, notifies the distribution management serv- 
er 16 (step S33). This notice contains the information 
specifying the program which has been deactivated, or 
specifically, the information specifying the basic block 
storing the program. 

[1.4.10.4] Deactivation completion notice 

[0089] The distribution management server 16, upon 
receipt of a program deactivation end notice from the 
UIM 12, determines, based on the notice, the basic 
block of the UIM 12 storing the program of which the 
deactivation has been completed. The information to the 
effect that the deactivation is complete is registered in 
the storage area of the data base prepared for the par- 
ticular basic block. 

[0090] Upon registration of completion of the deacti- 
vation, the distribution management server 16 notifies 
the contents server 19 of the completion of the deacti- 
vation (step S34). 



[1.4,11] Deletion (only when desired by user) 

[0091] A deactivated program wastefully occupies a 
memory area in the UIM 12, It is desirable for both the 
5 user and the contents providerto delete such an unnec- 
essary program. The deletion of the program, however, 
cannot be left to the user. If the user arbitrarily deletes 
the program in the UIM 12, the rent charging process 
for the UIM would continue to proceed in spite of the 
w program deletion, unless the fact of deletion is notified 
to the distribution management server 16 immediately. 
[0092] According to this embodiment, therefore, 
whenever the user desires to delete a program, the pro- 
gram is deleted underthe control of the distribution man- 
's agement server 1 6 

[0093] A deletion, based on a reason on the side of 
the contents provider, is basically not permitted due to 
the resulting complication of the charging process. 
[0094] The operation of deleting a program in re- 
20 sponse to the desire of the user will be explained below 
with reference to Figs. 10 and 15. 

[1.4,11.1] Program deletion request 

25 [0095] The user accesses a predetermined home 
page of the contents provider by operating the operating 
section 22 of the mobile terminal 11 . A distribution menu 
screen D11 shown in Fig. 15 is displayed on the display 
screen of the display section 21 of the mobile terminal 

30 11 , This distribution menuscreen D11 is provided bythe 
contents server 19 of the contents provider distributing 
the program. When the user selects a menu item mean- 
ing the deletion of a program, a screen D1 2 asking the 
userwhetherthe deletion can be carried out is displayed 

35 on the display section 21 of the mobile terminal 11 , as 
shown in Fig. 15. 

[0096] The user performs the operation permitting the 
deletion. The mobile terminal 11 transmits a program 
(applet) deletion request to the contents server 19 

40 through the network (step S41), This request contains 
the information specifying the program to be deleted. 
[0097] Withthetransmission of aprogram deletion re- 
quest, a screen D1 3 indicating thatthe deletion is going 
on. is displayed as shown in Fig. 15 on the display sec- 

45 tion 21 of the mobile terminal 1 1 . 

[1.4.11.2] Deactivation request to distribution 
management server 

so [0098] The contents server 19, upon receipt of a pro- 
gram deletion request, sends a deactivation request to 
the distribution management server 1 6 (step S42). This 
deactivation request contains the information specifying 
the mobile terminal 11 of the user requesting the pro- 

55 gram deletion and the information specifying the pro- 
gram to be deleted 
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[1.4,11.3] Deactivation request to UIM 

[0099] The distribution management server 16. upon 
receipt of a deactivation request, accesses the data- 
base and determines a basic block storing the program 
to be deleted. Then, the distribution management server 
16 sends a deactivation request containing the informa- 
tion specifying the particular basic block to the mobile 
terminal 1 1 of the user requesting the program deletion 
(step S43). 

[0100] This deactivation request is sent to the UIM 12 
through the mobile terminal 11 . The UIM 12resets, from 
"1 " to "0" the activation flag prepared for the basic block 
specified by the deactivation request. After that, the ex- 
ecution of the program in the particular basic block is 
prohibited. 

[1.4,11 .4] Deactivation end response 

[0101] The UIM 12, at the end of the program deacti- 
vation, transmits a deactivation end notice to the distri- 
bution management server 16 (step S44). This notice 
contains the information specifying the basic block stor- 
ng the program deactivated 

[1.4,11 .5] Deactivation end notice 

[0102] The distribution management server 16, upon 
receipt of the program deactivation end notice from the 
UIM 12, registers the information to the effect that the 
deactivation is complete, in the area of the data base 
corresponding to the basic block of the UIM 12 specified 
by the deactivation end notice. 
[0103] The distribution management server 1 6 sends 
aprogram deactivation end notice tothecontentsserver 
19 (step S45), 

[1.4,11 .6] Deletion request to distribution management 
server 

[0104] The contents server 19, upon receipt of the de- 
activation end notice for the program to be deleted, from 
the distribution management server 16, requests the 
distribution management server 1 6 to delete the partic- 
ular program (step S51). 

[1.4,11 .7] Deletion request to UIM 

[0105] The distribution management server 16, upon 
receipt of the program deletion request, sends a pro- 
gram deletion request to the UIM 12 of the user who 
requests the program deletion (step S52). This program 
deletion request contains the information specifying the 
basic block storing the program to be deleted. 
[0106] The program deletion request is sent to the 
UIM 12 through the mobile terminal 11 . The UIM 12 de- 
letes the program in the basic block specified by the pro- 
gram deletion request. 



[1.4,11.8] Deletion end response 

[0107] The UIM 12, atthe end of the program deletion, 
transmits a deletion end notice indicating the program 

5 deletion to the distribution management server 1 6 (step 
S53), This deletion end notice contains the information 
specifying the basic block from which the program is de- 
leted and the program deleted. At the same time, a 
screen D14 indicating the end of deletion is displayed, 

'0 as shown in Fig, 15, on the display section 21 of the 
mobile terminal 11 . 

[1.4,11.9] Deletion completion notice 

'5 [0108] The distribution management server 1 6, upon 
receipt of the deletion end notice from the UIM 12, reg- 
isters the information to the effect that the program has 
been deleted in the storage area in the data base cor- 
responding to the combination of the user requesting the 

20 deletion and the program deleted. 

[0109] Then, the distribution management server 16 
sends to the contents server the notice that the program 
deletion is complete (step S54). 
[0110] In the case where the charge process against 

25 the contents provider has been made for the program 
deleted, the distribution management server ceases to 
charge the contents provider thereafter. 

[1.4,12] Deletion (only when desired by distribution 
30 management server) 

[0111] According to this embodiment, a program may 
be deleted by other than the intention of the user. An 
example is the expiry of a predetermined term during 
35 which a program can be used. 

[01 1 2] The operation for deleting a program underthe 
guidance of the distribution management server in such 
a case will be described below with reference to Fig. 11 . 

40 [1.4,12.1] Deactivation requestto UIM 

[0113] If the usable term of a program has expired and 
the program is required to be deleted, the distribution 
management server 16 by accessing the data base, de- 

45 termines all the UIMs 12 to which the program to be de- 
leted has been distributed and the basic blocks storing 
the program to be deleted in each of the UIMs 12, and 
sends a deactivation request to each of the UIMs 12 
(step S61). Each deactivation request contains the in- 

50 formation specifying the basic block storing the program 
to be deleted. 

[0114] The deactivation request is sent to each UIM 
12through the mobile terminal 11. The UIM 12 resets, 
from "1" to "0", the activation flag corresponding to the 
55 basic block specified by the deactivation request. After 
that, the execution of the program in the particular basic 
block is prohibited. 
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[1.4,12.2] Deactivation end response 

[0115] At the end of the deactivation, the UIM 12 
transmits a deactivation end notice to the distribution 
management server 16 (step S62). 

[1.4,12.3] Deactivation completion notice 

[0116] The distribution management server 16 : upon 
receipt of the deactivation end notice from the party to 
which the program to be deleted has been distributed, 
registers the information indicating the completion of the 
deactivation in the storage area of the data base formed 
for the particular program. 

[01 17] The distribution management server 1 6 sends 
a program deactivation completion notice to the con- 
tents server 19 (step S63). 

[1.4,12.4] Notification of deactivation completion notice 
receipt to distribution management server 

[0118] The contents server 16, upon receipt of the de- 
activation completion notice from the distribution man- 
agement server 1 6, sends a deactivation receipt notice 
to the distribution management server 1 6 (step S64). 

[1.4,12.5] Deletion request to UIM 

[0119] The distribution management server 16, upon 
receipt of the deactivation receipt notice, sends a pro- 
gram deletion requesttothemobileterminal 11 that has 
transmitted the deactivation completion notice corre- 
sponding to the deactivation receipt notice (step S71). 
The deletion request sent to the mobile terminal 11 con- 
tains the information specifying the basic block storing 
the program to be deleted. 

[0120] The UIM 12, upon receipt of the deletion re- 
quest through the mobile terminal 11, deletes the pro- 
gram in the basic block specified by the request. 

[1.4,12.6] Deletion end response 

[0121] TheUlM 12,attheendoftheprogramdeletion, 
transmits a deletion end notice to the distribution man- 
agement server 1 6 (step S72). This notice contains the 
nformation specifying the basic block from which the 
program has been deleted. 

[1.4,12.7] Deletion completion notice 

[0122] The distribution management server 16, upon 
receipt of the deletion end notice from all the parties to 
which the program to be deleted has been distributed, 
registers the information to the effect that the program 
has been deleted, in the storage area of the data base 
formed for the particular program to be deleted. 
[0123] The distribution management server 1 6 sends 
a deletion completion notice to the contents server 19 



(step S73). 

[0124] At the sametime, the distribution management 
server ceases the charging process which may have 
hitherto been made against the contents providerforthe 
5 deleted program. 

[1 .4.12.8] Deletion result receipt notice to distribution 
management server 

'0 [0125] The contents server 19, upon receipt of the de- 
letion completion notice from the distribution manage- 
ment server 16, sends a deletion result receipt notice to 
the distribution management server 16 (step S74). 

'5 [1.4,13] Program distribution process for UIM version 
management 

[0126] The contents server 1 9 may be required to dis- 
tribute a program voluntarily regardless of the desire on 

20 the part of the user. An upgrade of the program that has 
been distributed is a case in point. 
[0127] In such a case, the distribution of the program 
of a new version to the UIMs 1 2 of all the users to which 
the particular program has been distributed gives rise to 

25 an inconvenience. This is by reason of the fact that the 
mobile terminals 11 are of various models, and the UIM 
specifications have various versions, It may happen, 
therefore, that a program of a new version, if sent to all 
the UIMs, can be executed normally only by the UIMs 

30 having a version issued at a certain time point or there- 
after. 

[0128] According to this embodiment, at each time of 
an upgrade of a program, a version notice request is 
sent to the UIMs and based on the response to the re- 

35 quest, it is determined whetherthe program is to be dis- 
tributed or not to a given UIM. This operation is shown 
in Fig. 12. Some of the UIMs 12 support the function of 
notifying the version thereof in response to the version 
notice request, and others do not. Fig. 12 shows the op- 

40 eration performed in the case where a version notice 
request has been sent to a UIM supporting such a func- 
tion and the operation performed in the case where a 
version notice request has been sent to a U IM not sup- 
porting the function 

45 

[1.4,13.1] Operation for UIM supporting version notice 
function 

[1.4,13.1.1] Program distribution request to distribution 
so management server 

[0129] Priorto distribution of a program after upgrade, 
the contents server 1 9 sends to the distribution manage- 
ment server 16 a program distribution request contain- 
55 ing the information specifying the program and the ver- 
sion information indicating the version of the UIM 1 2 that 
can execute the particular program (step S81). 
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[1.4,13.1.2] Version notice requestto UIM 

[0130] Tha distribution management server 16. upon 
receipt of the program distribution request, accesses the 
data base, determines all the mobile terminals 11 to 
which the program specified by the program distribution 
request has been distributed, and sends a version no- 
tice request to the mobile terminals 1 1 thus determined 
(step S82). 

[1.4.13.1.3] Version notice 

[0131] The version notice request is sent to each UIM 
12 through the mobile terminal 11. The UIM 12, upon 
receipt of the version notice request, notifies the version 
thereof to the distribution management server 16 (step 
S83). 

[1.4,13.1.4] No program distribution notice 

[0132] The distribution management server 16 re- 
ceives aversion notice from each UIM 12. In the case 
where the version notice received from a given UIM 12 
fails to meet the conditions indicated by the version in- 
formation from the contents server 19, the contents 
server 1 9 is notified that the program cannot be distrib- 
uted to the particular UIM 12 (step S84). 
[0133] In the case where the version notice received 
from another given UIM 12 meets the conditions indicat- 
ed by the version information from the contents server 
19, on the other hand, the distribution management 
server 16 distributes the program to the particular UIM 
12. This operation is described above with reference to 
Figs. 6 and 8. 

[1.4,13.2] Operation for UIM not supporting version 
notice function 

[1.4.13.2.1] Program distribution requestto distribution 
management server 

[0134] The contents server 19 sends a program dis- 
tribution request to the distribution management server 
16 in the same manner as described above (step S91). 

[1.4,13.2.2] Version notice requestto UIM 

[0135] The distribution management server 1 6 sends 
aversion notice requestto the UIM 12 of the mobile ter- 
minal 11 (step S92). 

[1.4,13.2.3] Timer count 

[0136] In this case, the UIM 12 does not support the 
version notice function, and therefore makes no re- 
sponse, 

[0137] Thus, the distribution management server 16 
monitors the timer and upon expiry of a predetermined 



time-out period (step S93) sends a version notice re- 
quest again to the UIM 12ofthemobileterminal11 (step 
S94), Then, the value on the retry counter is increment- 
ed by one. 

5 [0138] In a similar fashion, the distribution manage- 
ment server 1 6 monitors the timer, and upon expiry of a 
predetermined time-out period (step S95) sends aver- 
sion notice request again to the UIM 12 of the mobile 
terminal 11 (step S96). Then, thevalue of the retry coun- 

'0 ter is incremented by one. 

[1.4,13.2.4] No program distribution notice 

[0139] Once again, the distribution management 
'5 server 1 6 monitors the timer, and upon expiry of a pre- 
determined time-out period (step S97), sends a version 
notice request again to the UIM 1 2 of the mobile terminal 
11 (step S98). Then, the value on the retry counter is 
incremented by one, 
20 [0140] In the case where thefigure on the retry coun- 
ter reaches a predetermined value (3 in this case), the 
distribution management server 1 6 determines that the 
version of the UIM 12 fails to meettheconditionsforthe 
version notified from the contents server 1 9, and sends 
25 a no-program distribution notice to the contents server 
19 (step S84). 

[0141] As a result, the contents server 19 confirms 
that the program of which distribution is desired, cannot 
be distributed. 

30 

[1.4.14] Program distribution process based on UIM 
memory capacity limitation 

[0142] The limitation of the memory capacity of the 
35 UIM 1 2 may make the program distribution impossible, 
even if desired by the contents server 19. An example 
of the operation performed in such a case is shown in 
Fig. 13. This operation will be explained below. 

40 [1.4,14.1] Rejection by distribution management server 

[0143] The contents server 19 requests the distribu- 
tion management server 16, by attaching the program 
to be distributed, to send a program distribution request 

45 to the UIM 12 (step S1 01). 

[0144] The information indicating the memory state of 
each UIM is registered in the database of the distribution 
management server 16. The distribution management 
server 16, upon receipt of the program distribution re- 

50 quest to a given UIM 12, accesses the data base, and 
determines whether the basic block for the particular 
UIM 12 is available for storage, or if available, is too 
small in capacity to store the program (the capacity may 
vary from one version to another of UIM) or whether 

55 there is any other stumbling block to the program distri- 
bution. 

[0145] In the case where the program cannot be dis- 
tributed, the distribution management server 16 sends 
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a notice to the contents server 1 9 that the program can- 
not be distributed due to the shortage of the memory 
capacity (step S102). 

[0146] As a result the contents server 19 confirms 
that the program for which distribution is desired, cannot 
be distributed, 

[1.4.14.2] Rejection by UIM 

[0147] The memory capacity and the current occu- 
pancy state of each UIM 12 are registered in the data- 
base of the distribution management server 16. For 
some reason or other, however, the actual UIM memory 
state may differfrom the memory state registered in the 
database of the distribution management server 1 6. The 
operation performed in such a case is described below. 
[0148] First, the contents server 1 9 sends a program 
distribution request together with a program to the dis- 
tribution management server 16 (step S111), 
[0149] The distribution management server 16 ac- 
cesses the data base and determines whether the basic 
block of the destination UIM 12 is available for storage 
and has a sufficient capacity. 
[0150] In the case where the determination is YES : 
the distribution management server 1 6 sends a write re- 
quest together with the program to the UIM 12 (step 
S112). 

[0151] The UIM 12thathas received the write request 
determines whether the program attached to the write 
request can be stored in any one of the basic blocks or 
not. In the case where the determination is NO, the UIM 
12 sends a no-program distribution notice to the distri- 
bution management server 16 due to lack of memory 
capacity (step S1 13). 

[0152] The distribution management server 16, upon 
receipt of the no-program distribution notice due to lack 
of memory capacity, sends it to the contents server 19 
(step S114). 

[0153] From this notice, the contents server 19 can 
confirm that the program cannot be distributed to the 
UIM to which the distribution is desired. 
[0154] It may also happen that a program cannot be 
stored in abasicblockduetoawrite error in the memory 
of the UIM 12 or the malfunction of the memory device. 
In such acase, exactly the same operation as described 
above is performed. Fig. 14 shows such an operation. 
In Fig. 14, steps S121 to S1 24 correspond to steps S1 11 
to S114 in Fig. 13 and represent exactly the same op- 
eration, respectively. 

[1.4,15] Specific example of operation 

[0155] Now, a specific example of the operation ac- 
cording to this embodiment will be explained. 

[1 .4,15.1] Execution of program stored in UIM 

[0156] In this example of an operation, assume that a 



program called " O O RAILWAY" is stored in the basic 
block 40 1 of the UIM 12. 

[0157] The user operates the operating section 22 of 
the mobile terminal 11 and thus accesses the home 

5 page of the contents provider that has distributed the 
"OO RAILWAY" program. A distribution menu screen 
D21 as shown in Fig. 16 is displayed on the display 
screen of the display section 21 . This distribution menu 
screen D21 is provided by the contents server 19 of the 

'0 contents provider. The user performs the operation for 
selecting an item concerning the purchase of a commu- 
tation pass from the menu displayed on the distribution 
menu screen D21 , A purchase request for the commu- 
tation pass is transmitted from the mobile terminal 1 1 to 

'5 the contents server 1 9 through the network. 

[0158] As a result, a download screen D22 is sent 
from the contents server 19 to the mobile terminal 11 
and displayed on the display section 21 . The download 
screen D22 contains a menu of several value data hav- 

20 ing the same monetary value as the commutation pass. 
[0159] Once the user selects the desired value data, 
the information requesting the selected value data is 
sent to the contents server 1 9 from the mobile terminal 
11 

25 [0160] After that, the contents server 19 sends to the 
mobile terminal 11 thescreen data for selecting a meth- 
od of account settlement. As a result, a screen D23 is 
displayed by the mobile terminal 11 , The user selects 
"SELECT FROM UIM MENU" from the menu items in 

30 the screen D23, and thus can settle the account by use 
of the program in the UIM 12. Specifically, once this se- 
lect operation is performed, the UIM 12 is notified of the 
fact, Upon receipt of this notice, the control unit of the 
UIM 12 returns to the mobile terminal 11 the list of the 

35 programs stored in the basic blocks 40-1 to 40-6. The 
screen D24 containing this list is displayed on the dis- 
play section 21 of the mobile terminal 1 1 . The user se- 
lects a settlement program from the list. The selected 
program is executed by the UIM 1 2 thereby to settle the 

40 account, 

[0161] Assume that the account is settled by execut- 
ing the program in the program area 41 of the basic 
block 40-2. The data area 42 of the same basic block 
40-2 is used for settling the account. 

45 [0162] The contents server 19, upon detection that 
the account has been settled, sends the value data of 
the commutation pass included in the commutation pass 
purchase request described above, to the mobile termi- 
nal 11 . This value data contains the information such as 

so the names of the two stations involved, the validity term, 
the name of the user and the age of the user and are 
sent from the mobile terminal 11 to the UIM 12. The val- 
ue data, which are to be used for the "OO RAILWAY" 
program, are stored in the data area 42 of the basic 

55 block 40-1 corresponding to the same data in the UIM 
12. 
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[1.4,15.2] Mail order sale using network 

[0163] In this example of an operation, a program for 
a mail order sale is stored in the basic block 40-2 of the 

UIM 12, 

[0164] The user accesses the home page of the con- 
tents provider by operating the operating section 22 of 
the mobile terminal 11, so that a distribution menu 
screen D31 shown in Fig. 1 7 is displayed on the display 
section 21 of the mobile terminal 11. This distribution 
menu screen D31 is provided by the contents server 1 9 
of the contents provider which in turn provides the mail 
order sale (what is called "e-commerce") service utiliz- 
ing the network. The userselects the desired commodity 
(MATSUZAKA BEEF FOR SUKIYAKI, Y5000/KG, in 
Fig. 17) from the commodities listed in the distribution 
menu screen D31 . Then, a purchase request is trans- 
mitted fromthe mobile terminal 11 to the contents server 
19 through the network. 

[0165] The contents server 19 that has received the 
purchase request returns a settlement method screen 
D32 to the mobile terminal 11. As a result, a select 
screen D32 is displayed on the display section 21 . 
[0166] From the settlement methods listed in the se- 
lect screen D32, the user is assumed to have selected 
"XX BANK". The settlement program for XX Bank stored 
in the basic block 40-3 of the UIM 12 is started by the 
control unit 30 of the UIM 12 and a settlement screen 
D34 is displayed. 

[0167] The user inputs the personal identification (ID) 
number as settlement information. The mobile terminal 
11 tries to connect the settlement server for XX Bank 
through a communication unit 34 and the network, so 
that the screen D35 being accessed is displayed. 
[0168] Upon complete authentication, a purchase 
amount confirmation screen D36 is displayed. 
[0169] The user confirms the amount to be paid and 
nputs the confirmation. The mobile terminal 1 1 displays 
a payment confirmation screen D37 of the contents pro- 
vider, i.e. the mail order house, together with the delivery 
date, etc, 

[1.4,15.3] Use of commutation pass (check gate 
passage, manual start) 

[0170] According to this embodiment, the mobile ter- 
minal 11 can be used as a commutation pass by storing 
an appropriate program in the UIM 12. An example of 
operation will be explained below. 
[0171] First, the user depresses a button 23. A UIM 
menu screen D41 shown in Fig. 18 is displayed on the 
display section 21 , The user selects "OO RAILWAY" for 
which the commutation pass is used. As a result, the 
control unit 30 of the UIM 12 executes the CO RAILWAY 
program in the basic block 40-1 , so that a menu screen 
D42 is displayed on the display section 21 
[0172] When the screen D42 is displayed, the userse- 
lects "4. SET APPLICATION AUTO, START". An auto- 



matic start set confirm screen D43 is displayed thereby 
prompting the user to select. 

[0173] In the case where the user selects "YES", the 
automatic start is set. I n the case where the user selec- 
5 tion is "NO", on the other hand, the automatic start is not 
set. 

[0174] The gate of the railway company is equipped 
with a ticket check reader/writer. Before passing through 
the gate, the user performs the following operation. 
JO [0175] First, the user depresses the U button 23. The 
UIM menu screen D41 shown in Fig. 19 is displayed on 
the display section 21 .The user then selects " OORAIL- 
WAY" for which the pass is used. As a result, thecontrol 
unit 30 of the UIM 12 executes the CO RAILWAY pro- 
's gram in the basic block 40-1, and displays the menu 
screen D42 on the display section 21 . The user selects 
" 1 . PASS". The pass program constituting a part of the 
CO RAILWAY program is started by the control unit 30. 
In accordance with this pass program, the control unit 
20 30 begins communication with the ticket reader/writer 
for pass check. In the case where this communication 
is carried out by the common key cryptosystem, for ex- 
ample, the pass check process is performed following 
the steps described below. 

25 

(1) Each party checks the other party. 

(2) The ticket check reader/writer requests the mo- 
bile terminal 11 to transmit information on the com- 
mutation pass. 

so (3) The mobile terminal 1 1 encrypts the pass infor- 
mation by the common key and transmits it to the 
ticket check reader/writer. The pass information dis- 
play screen D53 is displayed on the display section 
of the mobile terminal 11. 

35 (4) The ticket check reader/writer decrypts the re- 
ceived commutation pass information, and, in the 
case where the user is found to be legitimate, the 
gate is opened to allow him in. 

40 [0176] At the same time, a message screen D54 for 
expressing gratitude to the user is displayed on the dis- 
play section 21 . 

[0177] The foregoing description deals with the com- 
mutation pass. In thecase where the mobile terminal 11 
45 i s US ed to function as a private card, however, the data 
area 42 is updated to indicate the value data corre- 
sponding to the amount after subtracting the actual 
charge in the process of (4) above, 

so [1.4,15.4] Use of commutation pass (gate passage: 
auto, start) 

[0178] When the screen D43 shown in Fig. 18 is dis- 
played, the user can select "YES" and the automatic 
55 start is set. The following operation is performed. Spe- 
cifically, when the mobile terminal 11 setto the automat- 
ic start mode approaches the gate of the station, a poll- 
ing signal transmitted from the ticket check reader/writer 
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is received by the mobile terminal 11. As a result, the 
pass program constituting a part of the 00 RAILWAY 
program is automatically started by the control unit 30 
in the UIM 12 and the pass check similarto the manual 
start is carried out. 

[1 .5] Effect of first embodiment 

[0179] As described above : according to this embod- 
iment, even in the case where the storage area of the 
storage module is divided to store each program, the 
mobile terminal simply provides the communication 
function to the UIM, and no extra burden is imposed on 
the mobile terminal. Therefore, the inherent function of 
the mobile terminal is not adversely affected 
[0180] Also, the program storage, the activation, the 
deactivation and the deletion are not carried out by the 
mobile terminal, but under the control of the distribution 
management server, Thus, the user convenience is im- 
proved while at the same time maintaining security. 

[2] Second embodiment 

[0181] According to the first embodiment described 
above, the program executed by the UIM 12 is stored in 
the basic blocks 40-1 to 40-6 in the same UIM, In the 
second embodiment, however, all the programs execut- 
ed are not necessarily stored in the basic blocks. 

[2.1] Configuration of second embodiment 

[0182] Fig. 21 is a block diagram showing a configu- 
ration of a program distribution system according to a 
second embodiment of the invention. 
[0183] A UIM 12, contents servers 19-1 to 19-6 and 
19X and a distribution management server 16A are 
shown in Fig. 21. The distribution management server 
16A corresponds to the distribution management server 
16 of the first embodiment plus the functions unique to 
this embodiment. The contents servers 19-1 to 19-6 and 
19X have similar functions to the contents server 19 of 
the first embodiment. The system according to this em- 
bodiment has an authentication server, as in the first em- 
bodiment, not shown in Fig, 21. 
[0184] The UIM 12 according to this embodiment in- 
cludes an application area 12C shown in Fig. 22 in place 
of the application area 12Bof the first embodiment. The 
program storage area 12C is divided into seven basic 
blocks 40-1 to 40-7 and one free basic block 40-1 . 
[0185] The basic blocks 40-1 to 40-7 and the free ba- 
sicblock40-F1 each have a program area41 andadata 
area 42. A program (application or applet) is stored in 
the program area 41 . The data area 42, on the other 
hand, has stored therein the data used by the program 
stored in the program area 41 of the same basic block 
or the free basic block. 

[0186] In this case, the basic blocks 40-1 to 40-7 and 
the free basic block 40-F1 are independent of each oth- 



er, and basically, the program stored in the program area 
41 of a given block cannot access the data area 42 of 
other blocks. This is also the case with the first embod- 
iment. The program stored in the program area 41 can- 

5 not be distributed or deleted without intermediary of the 
distribution management server 1 6A. The data area 42, 
however, can be directly operated through the distribu- 
tion management server 16A or a local terminal as in 
the case where electronic money is downloaded from 

'0 the ATM. This point is also similarto the first embodi- 
ment. 

[0187] According to this embodiment, the distribution 
of the programs stored in the basic blocks 40-1 to 40-7 
is controlled by the distribution management server 
'5 1 6A. The program stored in the free basic block 40-F1 , 
however, is controlled not by the distribution manage- 
ment server 16A but on the user's own responsibility. 
[0188] According to the first embodiment, the pro- 
gram transmitted from the contents server 19, in accord- 
20 ancewith the distribution request from the mobile termi- 
nal 11 , is sentto the UIM 12 by the distribution manage- 
ment server 16. The distribution management server 
16A according to this embodiment, on the other hand, 
accepts the program distribution request from the mo- 
ss bile terminal 11, and on acquiring the program by ac- 
cessing the contents server as required, distributes it to 
the UIM 12 of the mobile terminal 11, The distribution 
management server 1 6A according to this embodiment 
is similar to the distribution management server 16 of 
30 the first embodiment in that the program distribution 
from the contents server to the UIM 12 is relayed and 
managed. This operation, however, is not the only func- 
tion of the distribution management server 1 6A accord- 
ing to this embodiment, Specifically, the distribution 
35 management server 16A has means for storing a pro- 
gram orthe information indicating the location of the pro- 
gram for the benefit of the user of the UIM 12, and any 
of the programs stored in this means can be acquired 
by the userth rough the distribution management server 
40 1 6A. In this sense, the distribution management server 
16A exhibits a function similar to a cache memory for 
the UIM 12. 

[0189] In order to manage the program distribution to 
the UIM 12 and exhibit thef unction like a cache memory, 
45 the distribution management server 1 6A includes a dis- 
tribution management unit 50. The distribution manage- 
ment unit 50 has a user information storage unit 51 and 
a program information storage unit 52. 
[0190] The program information storage unit 52 has 
so stored therein a program proper or a URL corresponding 
to the program that can be distributed to the UIM 12. 
The URL is the information indicating the address of a 
specific one ofthe contents servers 19-1 to 19-6 and the 
very contents server where a particular program is lo- 
ss cated. Which is to be stored in the program information 
storage unit 52 for a given program, the URL information 
orthe program proper, can be determined based on the 
storage capacity ofthe program information storage unit 
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52, or in the case where the storage capacity is suffi- 
cient, can be selected as desired by the contents pro- 
vider operating the distribution server. 
[0191] The chance of storing a new program or the 
URL thereof in the program information storage unit 52 
is given, for example, in the case where the mobile ter- 
minal 11 of a given user sends a program distribution 
request, and a program or the URL thereof meeting the 
particular distribution request is not stored in the pro- 
gram information storage unit 52. In such a case, the 
program information storage unit 52 accesses the con- 
tents server and acquires and stores the program de- 
sired by the user, in compliance with the request from 
the mobile terminal 11 . 

[0192] The user information storage unit 51 includes 
n (n > 1) individual user information storage units 53-1 
to 53-n corresponding to n persons to which the system, 
according to the invention, is applicable. Each individual 
user information storage unit 53-k has a real distribution 
nformation storage unit 54 and a virtual distribution in- 
formation storage unit 55. 

[0193] The real distribution information storage unit 

54 of the individual user information storage unit 53-k 
has stored therein pointer data correspondingto thepro- 
gram actually distributed to the UIM 12 of the user k. 
The pointer data is for indicating a particular area in the 
program information storage unit 52 where the program 
or the URL thereof is stored. The availability of the real 
distribution information storage unit 54 makes it possible 
for the distribution management server 1 6A to immedi- 
ately redistribute any program, if erased, in the basic 
blocks 40-1 to 40-7 of the UIM 12. 

[0194] The virtual distribution information storage unit 

55 of the individual user information storage unit 53-k. 
on the other hand, stores the pointer data corresponding 
to an available program, though not actually distributed 
to the UIM 12 of the user k, that can be immediately dis- 
tributed to the UIM 12 of the user k who is desirous of 
having such a program. The user of the UIM 12 can re- 
ceive the following services by use of the virtual distri- 
bution information storage unit 55. 

(a) The pointer data of a program of which distribu- 
tion to the UIM 1 2 is desired is provisionally stored 
in the virtual distribution information storage unit 55. 
The user, whenever the distribution of the program 
with the pointer data thereof stored in the virtual dis- 
tribution information storage unit 55 is required, 
sends a request to the distribution management 
server 1 6A using the mobile terminal 1 1 . The distri- 
bution management server 16A reads the pointer 
data of the requested program from the virtual dis- 
tribution information storage unit 55, and acquires 
and distributes the program specified by the partic- 
ular pointer data to the UIM 12. In this case, the 
pointer data of the program distributed to the UIM 
12 is moved from the virtual distribution information 
storage unit 55 to the real distribution information 



storage unit 54. 

(b) The number of the basic blocks in the U IM 1 2 is 
limited. Therefore, it may happen that all the basic 
blocks are occupied and no basic block is available 
5 for storing the program to be distributed. In such a 
case, the distribution management server 16A 
reads the pointer data from the storage area corre- 
sponding to a given basic block 40-X intheUlM 12, 
from among the storage areas in the real distribu- 
te tion information storage unit 54, and transfers it to 
the virtual distribution information storage unit 55. 
The program to be distributed is sent to the UIM 12, 
where it is written in the basic block 40-X, and the 
pointer data of the program is written in the storage 
'5 area corresponding to the basic block 40-X in the 
real distribution information storage unit 54. This 
process makes it possible to acquire a program by 
a distribution request and store it in a basic block 
even in the case where the basic blocks are fully 
20 occupied. In the process, with regard to the program 
driven away from the basic block, a request may be 
given again, if required, to the distribution manage- 
ment server 16A and the process described in (a) 
above can be carried out. 

25 

[0195] Now, an explanation will be given of the func- 
tion of the distribution management server 16A corre- 
sponding to the free basic block 40-F1 . As already de- 
scribed, asforthefree basic block 40-F1 , the distribution 
30 management server 16 does not manage the program 
distribution. The user, by operating the mobile terminal 
11 , can freely register or delete a program in the free 
basic block 40-F1. 

[0196] The real distribution information storage unit 
35 54 of the individual user information storage unit 53 has 
a storage area corresponding to the basic block 40-F1 
of the UIM 12. In this area, however, no pointer data of 
a program is stored, but the data including the number 
of times a program is registered in or deleted from the 
40 basic block 40-F1 orthe URL information thereof. In the 
case where nothing is stored in the free basic block 
40-F1 , the data indicating the fact ("Null" data, etc.) may 
be stored in this area. 

[0197] The program in the free basic block 40-F1 of 
45 the UIM 12, should it be deleted, unlike the programs 
stored in the basic blocks 40-1 to 40-7, remains as it is 
until registered again by the user himself. 
[0198] In the case where the user is desirous of 
changing the program in the free basic block 40-F1 tem- 
so porarily to another program, on the other hand, such a 
change can be made always by the user himself rewrit- 
ing it, 

[0199] In such a case, the distribution management 
server 1 6A cannot carry out the charging process even 
55 if a program is stored in the free basic block 40-F1 . 
[0200] The free basic block 40-F1 can be changed so 
that it can be handled the same way as the basic blocks 
40-1 to 40-7 as desired by the user. Specifically, before 
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the change, seven basic blocks 40-1 to 40-7 and one 
free basicblock40-F1 can be used as eight basic blocks 
40-1 to 40-8. 

[0201] lnsuchacase,the information to theeffectthat 
the free basic block 40-F1 has been changed to the ba- 
sic block 40-8 is written by the distribution management 
server 16A in the system area 12A (Fig. 4) of the UIM 
12. Also, the area in the real distribution information stor- 
age unit 54 that has hitherto been handled as an area 
corresponding to the free basic block 40-F1 can be han- 
dled by the distribution management server 16A as an 
area corresponding to the basic block 40-8. and using 
this area, the same management as that of the basic 
blocks 40-1 to 40-7 is started. 
[0202] The basic block that has been changed to the 
basic block 40-8 by the user in this way can be restored 
to the free basic block 40-F1 again. The basic blocks 
40-1 to 40-7 cannot be changed to free basic blocks. 

[2.2] Configuration of distribution management server 

[0203] A configuration of the distribution management 
server is shown in Fig. 23. 

[0204] The distribution management server 16A is 
roughly configured of a transmission control unit 61 , the 
user information storage unit 51 described above, the 
program information storage unit 52 described above 
and a secure communication control unit 62. 
[0205] The transmission control unit 61 controls the 
transmission between the external contents servers 
19-1 to 19-6 or between the mobile terminals 11 (includ- 
ng the transmission between the contents servers 1 9-1 
to 19-6 and the mobile terminals 11), The transmission 
control unit 61 also controls the transmission between 
the user information storage unit 51 , the program infor- 
mation storage unit 52 and the secure communication 
control unit 63 to each other. Further, the transmission 
control unit 61 controlsthe distribution management unit 
50, the user information storage unit 51 ; the program 
nformation storage unit 52 and the secure communica- 
tion control unit 63 on the one hand, and requests the 
execution of various processes in the distribution man- 
agement unit 50, the user information storage unit 51. 
the program information storage unit 52 and the secure 
communication control unit 63 on the other hand 
[0206] The program information storage unit 52 sub- 
stantially functions as a portal site for the program per- 
mitted to be distributed to the basic blocks 40-1 to 40-7 
of the UIM 12. 

[0207] The secure communication control unit 63 au- 
thenticates the information (an encrypted program, etc.) 
sent from the contents servers 19-1 to 19-6, holds the 
public key paired with the private key held by each UIM, 
and manages the issue of the public keys for the con- 
tents servers 19-1 to 19-6. 



[2.3] Operation of second embodiment 

[2.3.1] Registration in user information storage unit 

5 [0208] n the example shown in Fig. 21 . the contents 
servers 1 9-1 to 1 9-6 are under the control of the distri- 
bution management server 1 6A. The user desirous of 
using a program (applet) stored in any of the contents 
servers is required to register the particular program in 

'0 the user information storage unit 51 of the distribution 
management server 16A. The registration process will 
be explained below with reference to Fig. 24. 
[0209] First, the user sends a request for a menu list 
of the programs that can be registered, to the distribution 

'5 management server 16A from the mobile terminal 11. 
This request is sent to the program information storage 
unit 52 through the transmission control unit 61 of the 
distribution management server 16A (step S131). 
[0210] The program information storage unit 52 that 

20 has received the request prepares a menu list of all the 
programs that can be registered or, specifically, all the 
programs of which the program proper or the URL is 
stored in the program information storage unit 52 and 
transmits the menu list through the transmission control 

25 unit 61 to the mobile terminal 11 (step S1 32). 

[0211] This menu list is received by the mobile termi- 
nal 11 and displayed on the display section 21 . Under 
this condition, the user can acquire, by operating the op- 
erating section 22, a comment on the desired program 

30 from the distribution management server 16A and dis- 
play it on the display section 21 
[0212] Once the program of which distribution is re- 
quested is determined by the user operating the oper- 
ating section 22, the mobile terminal 11 transmits a reg- 

35 istration request containing the information specifying 
the particular program to the program information stor- 
age unit 52 of the distribution management server 16A 
(step S133). 

[0213] The program information storage unit 52, 
40 based on the program registration request, registers the 
program requested by the user in the user information 
storage unit 51 (step S1 34), 

[0214] The operation in step S134 will be described 
in detail. First, assume that the registration request is 

45 issued from the mobile unit 11 in which the UIM 12 of a 
given user k is built or mounted. In this case, the pro- 
gram information storage unit52 ; based on the registra- 
tion request, identifies the program requested bythe us- 
er, and determines the pointer data for specifying the 

so internal area of the program information storage unit 52 
in which the URL information indicating the location of 
the program or the program proper thereof is stored. 
Once the pointer data of the program requested by the 
user is obtained in this way the program information 

55 storage unit 52 accesses the contents stored in each 
area of the real distribution information storage unit 54 
of the individual user information storage unit 53-k cor- 
responding to the user k, and thus determines the basic 
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block 40-X (1 s x s 7) available for storage among the 
basic blocks of the UIM 12 of the user k. The pointer 
data of the program requested by the user is registered 
in the area of the real distribution information storage 
unit 54 corresponding to the basic block 40-X (step 
S134). It may be that the UIM 12 of the user k has no 
basic block 40-X (15X57) available for storage. In 
such a case, the program information storage unit 52 
registers the pointer data in the virtual distribution infor- 
mation storage unit 55 designated by the user or set au- 
tomatically. 

[0215] In step S141 , the menu list may not have any 
desired program. In such a case, the user can request 
the program information storage unit 54, by operating 
the mobile terminal 1 1 , to access to the desired contents 
server. In this case, theprogram information storage unit 
54, in compliance with the user request, acquires the 
program or the URL thereof from the contents server 
desired by the user, and holds it in the unoccupied area 
in the program information storage unit 54. In the proc- 
ess, the pointer data indicating the location of the ac- 
quired program or the URL thereof is registered in the 
real distribution information storage unit 54 in the same 
manner as the procedure mentioned above. 
[0216] Upon complete registration of the program re- 
quested by the user in this way, the distribution manage- 
ment server 16A starts the charge process for the user 
or the contents provider that has distributed the partic- 
ular program. 

[0217] Then, the user information storage unit 51 
sends a registration notice to the mobile terminal 11 
through the transmission control unit 61 (step S135). 
[0218] The mobile terminal 1 1 , upon receipt of the reg- 
istration notice, sends a registration acknowledgment to 
the distribution management server 16A (step S136). 
[0219] The user information storage unit 51 , upon re- 
ceipt of the registration acknowledgment through the 
transmission control unit 61 from the mobile terminal 1 1 
having the UIM 12 of the user k built therein or connect- 
ed therewith, determines the contents provider 1 9 stor- 
ing the program of which the pointer data has been reg- 
istered for the user k, and sends an activation permis- 
sion request to the contents server 1 9 (step S137). 
[0220] The contents server 19 that has received the 
activation permission request, in orderto approve a pro- 
gram utilization contract, sends the activation permis- 
sion to the user information storage unit 51 (step S1 38). 
As a result, the user information storage unit 51 consid- 
ers that the use is permitted of the pointer data stored 
in that area of the real distribution information storage 
unit 54 of the individual user information storage area 
53-kforthe user k which corresponds to the basic block 
40-X. 

[0221] The user information storage unit 51 sends a 
registration completion notice indicating that the regis- 
tration in the mobile terminal 11 is completed (step 
S139). This registration completion notice contains a 
registration list providing a list of the programs with the 



pointer data thereof registered in the user information 
storage unit 51 

[0222] The user can confirm the registration list from 
the display section 21 of the mobile terminal 11 

5 

[2.3,1 .1 ] Registration of UIM in basicblock(thecontents 
server holding the program) 

[0223] The user k who has received the registration 
'0 list can request the program for which he has requested 
registration, to be distributed and written in the UIM 12. 
With reference to Fig. 25, this operation will be ex- 
plained. 

[0224] The user k performs the operation forselecting 

'5 a program of which distribution is desired from the reg- 
istration list. Then, a distribution request containing the 
pointer in the registration list, indicating the position 
number in the registration list where the particular pro- 
gram is located, is sent to the user information storage 

20 unit 51 of the distribution management server 16A from 
the distribution terminal 11 (step S141). 
[0225] The user information storage unit 51 , upon re- 
ceipt of a distribution request from the mobile terminal 
11 of the user k, reads the pointer data specifying the 

25 place of storing the program proper or the URL of the 
program requiring distribution, from that area of the real 
distribution information storage unit 54 of the individual 
user information storage unit 53-k which corresponds to 
the pointer in the registration list contained in the partic- 

30 ular distribution request. The distribution request con- 
taining the pointer data is sent to the program informa- 
tion storage unit 52 (step S142). 
[0226] The program information storage unit 52 ac- 
cesses the area specified by the pointer data in the par- 

35 ticular distribution request. In the case where the URL 
of the program is stored in the area, the program distri- 
bution is requested from the contents server 19 using 
the URL (steps 143). 

[0227] The contents server 19, upon receipt of this 
40 distribution request, requests the authentication server 
1 8 to issue a public key for the distribution management 
server (step S144). 

[0228] nthecasewherethecontentsserverie is per- 
mitted to write in the UIM 12, the authentication server 

45 1 s issues the public key for the distribution management 
server to the contents server 19 (step S145). 
[0229] The contents server 19 encrypts the program 
using the public key for the distribution management 
server, and distributes it as a program, with a certificate, 

so to the secure communication control unit 62 of the dis- 
tribution management server 1 6A (step S1 46). 
[0230] The secure communication control unit 62 has 
stored therein a distribution management server private 
key paired with the distribution management server pub- 

55 lie key, and using this private key, decrypts the program 
with a certificate. In the case where this decryption is 
successful, a program written in a common text is ob- 
tained. 
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